<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/07/2015 23:08, Chris Hofmann
      wrote:<br>
    </div>
    <blockquote
cite="mid:CA+zsDHDXF0236WbngK7yrBks5pBoxDdfnJuEgv1DSpcaP+q2bw@mail.gmail.com"
      type="cite">
      <div dir="ltr">On Fri, Jul 10, 2015 at 2:42 PM, Robert Kaiser <span
          dir="ltr"><<a moz-do-not-send="true"
            href="mailto:kairo@kairo.at" target="_blank">kairo@kairo.at</a>></span>
        wrote:<br>
        <br>
        > I personally wonder how this fits at all into the three
        pillars of Firefox development that were presented <br>
        > recently, and where the direct user benefit is in "killing
        XUL". That said, XUL was created as a transitional <br>
        > technology because HTML wasn't ready for UI (and it still
        isn't fully there yet, even though much further along)<br>
        <div class="gmail_extra"><br>
          <br>
        </div>
        <div class="gmail_extra">Yes that's a good topic to get
          conversation and investigation started.  I might be missing
          something but as far as I can see it does have a major
          contribution to any of the 3 pillars, and in several places
          maybe in direct conflict with plans around the 3 pillars.<br>
          <br>
        </div>
        <div class="gmail_extra">Shipping features as Addons and
          increasing our dependence on Addons is one example.  If we
          change the UI framework we would be needing to create a whole
          new extension, packaging and installation system for addons
          right at a time we would be becoming more reliant on addons,
          and would also need to figure mechanism to transition current
          addons to what ever this new addon system might be.  We would
          also need to be creating something that replaces overlays to
          UI content areas either in HTML or create multiple ways of
          doing this on each of the native platforms.<br>
        </div>
      </div>
    </blockquote>
    Work is ongoing on improving our add-on API system, "killing" XUL
    there.<br>
    <blockquote
cite="mid:CA+zsDHDXF0236WbngK7yrBks5pBoxDdfnJuEgv1DSpcaP+q2bw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">We would also need to transition
          localization systems and tools, and other things that XUL
          provides for now. <br>
        </div>
      </div>
    </blockquote>
    <br>
    I disagree with you that XUL as a UI language and layout module is
    used for localization. It isn't. Our l10n infrastructure is used
    from XUL, because we happen to use XUL for our UI, but the DTD and
    properties files that store the actual l10n data, as well as the
    XPCOM interfaces that provide access to them, are perfectly usable
    from elsewhere (and we do use them from (X)HTML/JS in certain
    cases).<br>
    <br>
    The list you provided in your other post:<br>
    <br>
    > Overlays, Themes, Addons, Packaging, Installation,
    Localization, etc...<br>
    <br>
    is actually quite short, given the above. I don't know what you mean
    by packaging and installation - our installer doesn't use XUL, I
    believe, and the packaging into jar files (just with HTML/JS under
    content/ instead of XUL/JS) could be kept if we wanted.<br>
    <br>
    And as David said, nobody is saying "let's just chuck it all out
    tomorrow without thinking about how to build a browser without
    them". But we are saying it's an area where we've invested less, and
    not just less but an order of magnitude (or two or three) less than
    in HTML, nor is it part of our core mission, and it is actively
    impeding some of the work we're doing.<br>
    <br>
    Examples of issues I can remember off the top of my head:<br>
    1) adding a single button to the toolbar of the main Firefox UI
    slows down startup and new window openings (talos!) by a few
    milliseconds spent in XUL layout / XBL construction alone.<br>
    2) XBL bindings that get removed at "odd"/unexpected times cause
    intermittent bugs<br>
    3) XUL flexbox + "new" flexbox mix badly together<br>
    4) panel and popup layout is "interesting" and causes serious bugs
    (cf. <a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1029937">https://bugzilla.mozilla.org/show_bug.cgi?id=1029937</a> )<br>
    5) XBL interacting weirdly with new CSS features (cf.
    <a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1093260">https://bugzilla.mozilla.org/show_bug.cgi?id=1093260</a>, quote from bz:
    "Welcome to XBL sucking.")<br>
    6) adopting "webby" toolkits like react/jquery/... (the Loop team is
    in a better position to talk about this than I am)<br>
    <br>
    and the list goes on.<br>
    <br>
    The status quo is not acceptable, and I haven't even started on how
    the technology gap hampers new contributors.<br>
    <br>
    ~ Gijs<br>
  </body>
</html>