<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 11, 2015 at 1:52 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 10/07/2015 23:08, Chris Hofmann
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">On Fri, Jul 10, 2015 at 2:42 PM, Robert Kaiser <span dir="ltr"><<a 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></span>
Work is ongoing on improving our add-on API system, "killing" XUL
there.<span class=""><br></span></div></blockquote><div><br></div><div><br>This kind of approach is great! But I'd call it incremental replacement of a component, not "killing" the big bad MF'er.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote 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></span>
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></div></blockquote><div><br></div><div>I depends on what alternative is chosen. This is not so easy if its native UI's that are chosen. Then we either will be hacking some transitional/transformational thing together, or be plugging directly into the different localization frameworks on the different platforms.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
The list you provided in your other post:<span class=""><br>
<br>
> Overlays, Themes, Addons, Packaging, Installation,
Localization, etc...<br>
<br></span>
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 href="https://bugzilla.mozilla.org/show_bug.cgi?id=1029937" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1029937</a> )<br>
5) XBL interacting weirdly with new CSS features (cf.
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1093260" target="_blank">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></div></blockquote><div><br></div><div>This list is useful. But its a one sided evaluation of the problem since it doesn't talk about how these problems in XUL might compare performance wise (or be solved by?) one solution (browser.html) or the other (native UI), or even others... That's the next big step in a thoughtful evaluation of which direction to head.<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
The status quo is not acceptable, and I haven't even started on how
the technology gap hampers new contributors.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></div></blockquote><div><br></div><div>how would the alternatives hamper new contributors?... if its a native solution that's chosen its a return to the bad old days that from which XUL was born. One platform races ahead at the expense of others since it attracts all the cool developers. Back at netscape it was a big pile of windows developers piling on "best of the web features of the day" racing to match Microsoft, and poor Mac and Xhead developers left struggling to catch up. The windows developers with poor cross platform experience constantly breaking things on Mac and Unix as they went... Both tinderbox and XUL were born from the tension around these problems.<br><br></div><div>Now days is Mac's on everyone's laps but all our users are on windows. Maybe this would force more balance but it still would tax new contributors. Hard to say. Or maybe your thinking browser.html is the chosen path; but I have not heard that. I mostly heard that "we don't know what solution might be better, and hence part of the confusion and awkwardness in getting this discussion going..."<br><br></div><div>-chofmann<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888">
~ Gijs<br>
</font></span></div>
</blockquote></div><br></div></div>