Moratorium on new XUL features

[Robert O'Callahan]

Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
desire for these features, but I do not think we should take these patches,
nor any other patches adding features to XUL. XUL is a dead-end technology
and investment in XUL provides minimal returns --- this includes effort
spent reviewing and maintaining XUL. Some amount of XUL maintenance is
necessary to support Firefox, Thunderbird and the Firefox addons ecosystem,
but we should keep it to a minimum. In most cases our apps and addons can
use standard Web platform technology instead, which continues to evolve
rapidly.

There may be some cases where small extensions to XUL provide great
benefits to the Mozilla project that we can't easily get any other way, in
which case we should allow it. I don't think bug 441414 is one of those
cases. With some effort you can build arbitrarily rich XUL-tree-like
functionality using HTML, and that's the way to go.

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[L. David Baron]

On Tuesday 2014-10-14 11:28 +1300, Robert O'Callahan wrote:
> Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
> desire for these features, but I do not think we should take these patches,
> nor any other patches adding features to XUL. XUL is a dead-end technology
> and investment in XUL provides minimal returns --- this includes effort
> spent reviewing and maintaining XUL. Some amount of XUL maintenance is
> necessary to support Firefox, Thunderbird and the Firefox addons ecosystem,
> but we should keep it to a minimum. In most cases our apps and addons can
> use standard Web platform technology instead, which continues to evolve
> rapidly.
>
> There may be some cases where small extensions to XUL provide great
> benefits to the Mozilla project that we can't easily get any other way, in
> which case we should allow it. I don't think bug 441414 is one of those
> cases. With some effort you can build arbitrarily rich XUL-tree-like
> functionality using HTML, and that's the way to go.

Agreed.

(And, really, I should have sent something like the above message
two weeks ago, but roc beat me to it.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Joshua Cranmer 🐧]

On 10/13/2014 5:28 PM, Robert O'Callahan wrote:
> Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
> desire for these features, but I do not think we should take these patches,
> nor any other patches adding features to XUL. XUL is a dead-end technology
> and investment in XUL provides minimal returns --- this includes effort
> spent reviewing and maintaining XUL. Some amount of XUL maintenance is
> necessary to support Firefox, Thunderbird and the Firefox addons ecosystem,
> but we should keep it to a minimum. In most cases our apps and addons can
> use standard Web platform technology instead, which continues to evolve
> rapidly.
>
> There may be some cases where small extensions to XUL provide great
> benefits to the Mozilla project that we can't easily get any other way, in
> which case we should allow it. I don't think bug 441414 is one of those
> cases. With some effort you can build arbitrarily rich XUL-tree-like
> functionality using HTML, and that's the way to go.

I nominally agree with this sentiment, but there are a few caveats:
1. nsITreeView and <xul:tree> exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
2. The main rationale for this feature (bug 213945, although I doubt the
approach currently taken in bug 441414 is actually usable for that
anyways) involves a tree view that is currently performance-sensitive
and comprises 13,446 lines of C++ code, so it can't easily move to JS.
Which means some sort of XPIDL API is going to be necessary anyways, and
that API would probably look vaguely similar to nsITreeView.
3. I've never done a lot of UI coding myself, so I don't know if my
recollection is correct anymore or even if it ever was, but I recall
hearing that XUL and HTML didn't get together terribly well.

So if we had an HTML tree implementation that:
a) supported lazy generation of row data
b) supported column pickers, rearrangeable columns, etc.
c) supported CSS queries similar to what <xul:tree> does already,
d) could be used or made usable from C++ without too much effort
e) already existed and were generally maintained in toolkit/
f) were properly accessible
g) had any other compatibility features I've neglected

I would happily agree with you. But without those, it does feel a little
bit like you're holding hostage real improvements on the basis that a
better solution theoretically exists.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Robert O'Callahan]

On Tue, Oct 14, 2014 at 12:06 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com>
wrote:

I nominally agree with this sentiment, but there are a few caveats:
> 1. nsITreeView and <xul:tree> exist and are usable in Mozilla code today.
> No HTML-based alternative to these are so easily usable.
> 2. The main rationale for this feature (bug 213945, although I doubt the
> approach currently taken in bug 441414 is actually usable for that anyways)
> involves a tree view that is currently performance-sensitive and comprises
> 13,446 lines of C++ code, so it can't easily move to JS. Which means some
> sort of XPIDL API is going to be necessary anyways, and that API would
> probably look vaguely similar to nsITreeView.
>

I'm not proposing migrating the current tree code to HTML+JS.

> 3. I've never done a lot of UI coding myself, so I don't know if my
> recollection is correct anymore or even if it ever was, but I recall
> hearing that XUL and HTML didn't get together terribly well.
>
> So if we had an HTML tree implementation that:
> a) supported lazy generation of row data
> b) supported column pickers, rearrangeable columns, etc.
> c) supported CSS queries similar to what <xul:tree> does already,
> d) could be used or made usable from C++ without too much effort
> e) already existed and were generally maintained in toolkit/
> f) were properly accessible
> g) had any other compatibility features I've neglected
>
> I would happily agree with you. But without those, it does feel a little
> bit like you're holding hostage real improvements on the basis that a
> better solution theoretically exists.
>

Nope.

[Andrew Sutherland]

On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote:
> I nominally agree with this sentiment, but there are a few caveats:
> 1. nsITreeView and <xul:tree> exist and are usable in Mozilla code
> today. No HTML-based alternative to these are so easily usable.

There are many lazy-rendering infinite tree/table/infinite list
implementations out there:

For example:
- Dojo: TreeGrind/LazyTreeGrid
http://dojotoolkit.org/reference-guide/1.10/dojox/grid/TreeGrid.html
- dgrid (Dojo related): http://dojofoundation.org/packages/dgrid/
- tree examples
- column hider extension:
https://github.com/SitePen/dgrid/blob/v0.3.15/doc/components/extensions/ColumnHider.md
- the things that the dgrid website provides in its comparison table
- Sencha (which is GPLv3 but has a weird library style exception it
seems): http://dev.sencha.com/ext/5.0.1/examples/tree/locking-treegrid.html
- React (just a list, but an example of how easy such a component is in
React): https://github.com/orgsync/react-list

> 2. The main rationale for this feature (bug 213945, although I doubt
> the approach currently taken in bug 441414 is actually usable for that
> anyways) involves a tree view that is currently performance-sensitive
> and comprises 13,446 lines of C++ code, so it can't easily move to JS.
> Which means some sort of XPIDL API is going to be necessary anyways,
> and that API would probably look vaguely similar to nsITreeView.

The performance-sensitive parts of the XUL tree view widget is that it
paints synchronously and does not do any smart caching on its own.
These are deficiencies of the C++ XUL tree implementation that an HTML
implementation need not share. (In fact, I've never seen any that would
have the same performance problems; you'd have to write your own widget
from the ground up in Canvas to reproduce them.)

For the bug 213945 Thunderbird use-case, the existing C++ nsITreeView
interface implemented by the mailnews DBView could easily be used by a
Dojo Store adapter/etc. Any calls made by C++ code to update the tree
view can (and already do) call JS code to cause proper invalidation of
the JS/HTML-exposed data-model. I say this as someone with expensive
experience working with that area of the Thunderbird codebase and who
considered our options and decided that an HTML-based widget was the way
to go.

> 3. I've never done a lot of UI coding myself, so I don't know if my
> recollection is correct anymore or even if it ever was, but I recall
> hearing that XUL and HTML didn't get together terribly well.
>
> So if we had an HTML tree implementation that:
> a) supported lazy generation of row data
> b) supported column pickers, rearrangeable columns, etc.
> c) supported CSS queries similar to what <xul:tree> does already,

The examples I give above I believe all support these features.

> d) could be used or made usable from C++ without too much effort

As noted above, I don't think Thunderbird's use-case actually requires
C++ code to meaningfully interact with the tree widget in a way that
can't be compensated for in JS.

> e) already existed and were generally maintained in toolkit/

This is a weird, NIH-ish requirement. Why should Mozilla create and
maintain an HTML tree widget when there are so many open source
implementations that already exist?

> f) were properly accessible

A good concern and something that should be used for evaluation of any
library options. Since the widgets above all use the HTML DOM, it's a
question of making sure they are using the appropriate HTML and ARIA
attributes (ex: aria-posinset).

Andrew

[Yonggang Luo]

I know there is so much alternative for tree in HTML/JS, but the simplest way is to improve tree directly when you have already use it.
If the XUL is truly dead, then mozilla community should consider to remove it totally from the codebase, but not reject to improve it.


在 2014年10月14日星期二UTC+8上午11时11分39秒，somb...@gmail.com写道：

[Joshua Cranmer 🐧]

On 10/13/2014 10:10 PM, Andrew Sutherland wrote:
> On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote:
>> I nominally agree with this sentiment, but there are a few caveats:
>> 1. nsITreeView and <xul:tree> exist and are usable in Mozilla code
>> today. No HTML-based alternative to these are so easily usable.
>
> There are many lazy-rendering infinite tree/table/infinite list
> implementations out there:

I found far fewer when searching, but I suppose I'm just bad at coming
up with search terms.

> e) already existed and were generally maintained in toolkit/
>
> This is a weird, NIH-ish requirement. Why should Mozilla create and
> maintain an HTML tree widget when there are so many open source
> implementations that already exist?

I suppose the requirement I really meant was "does not require a massive
toolkit to work properly." Taken to the extreme, we'd end up with a half
a dozen large JS toolkits being installed when we install Firefox--see
the current thread about Firefox installer size pondering. Also, I feel
that a Mozilla-maintained (or at least Mozilla-blessed) toolkit is far
more likely to solve issues that aren't normally in the thoughts of web
developers, e.g., accessibility.

From another point of view: Mozilla, for over a decade, provided a
relatively featureful toolkit for building UIs known as XUL. If the
argument is that we should be using HTML instead of XUL, then wouldn't
it make sense to provide an at-least-as-featureful HTML toolkit to make
migration easy and relatively painless?

[Jonas Sicking]

On Mon, Oct 13, 2014 at 8:56 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:
> From another point of view: Mozilla, for over a decade, provided a
> relatively featureful toolkit for building UIs known as XUL. If the argument
> is that we should be using HTML instead of XUL, then wouldn't it make sense
> to provide an at-least-as-featureful HTML toolkit to make migration easy and
> relatively painless?

I would love to make it easier for people to create long scrollable
lists for HTML. However it's a quite hard problem to solve. We're
doing some experimenting on this front in FirefoxOS. There's no reason
we couldn't do the same in Firefox Desktop UI as well.

/ Jonas

[Boris Zbarsky]

On 10/13/14, 11:28 PM, Yonggang Luo wrote:
> If the XUL is truly dead, then mozilla community should consider to remove it totally from the codebase

Working on it. It's a big project. ;)

-Boris

[Dirkjan Ochtman]

On Tue, Oct 14, 2014 at 2:29 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Working on it. It's a big project. ;)

Is there a tracker for this?

Cheers,

Dirkjan

[Robert O'Callahan]

On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com>
wrote:

> From another point of view: Mozilla, for over a decade, provided a
> relatively featureful toolkit for building UIs known as XUL. If the
> argument is that we should be using HTML instead of XUL, then wouldn't it
> make sense to provide an at-least-as-featureful HTML toolkit to make
> migration easy and relatively painless?

I already said I'm not proposing a wholesale migration here. Please stop
misconstruing me.

[Joshua Cranmer 🐧]

On 10/14/2014 5:12 PM, Robert O'Callahan wrote:
> On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com>
> wrote:
>
>> From another point of view: Mozilla, for over a decade, provided a
>> relatively featureful toolkit for building UIs known as XUL. If the
>> argument is that we should be using HTML instead of XUL, then wouldn't it
>> make sense to provide an at-least-as-featureful HTML toolkit to make
>> migration easy and relatively painless?
>
> I already said I'm not proposing a wholesale migration here. Please stop
> misconstruing me.

Nor am I proposing a wholesale migration.

[Yonggang Luo]

在 2014年10月14日星期二UTC+8下午8时29分04秒，Boris Zbarsky写道：

> On 10/13/14, 11:28 PM, Yonggang Luo wrote:
>
> > If the XUL is truly dead, then mozilla community should consider to remove it totally from the codebase
>
>
>
> Working on it. It's a big project. ;)

Well, indeed, i've seen so much simulated tree in HTML, it's totally slow and not performance good, and do not support for big data(1000,000+) indeed. So if mozilla community are working on it, there should be some equivalent for tree in HTML.
>
>
>
> -Boris

[glazou]

Seriously ?!?

Guys, you understand there is an ecosystem - even if it is a small one - of companies relying on XUL for their businesses? BlueGriffon, Postbox and more rely on XUL and XULRunner. So I have two questions:

1. does Mozilla still care about us? I have endlessly tried to discuss the fate of XUL and XULRunner with a previous Mozilla CEO, Gary Kovacs. He _never_ accepted to have a chat about it. I have the feeling we are left outside alone in a « too bad for you » move and I find it depressing.

2. since it's out of question to rebuild something as big as the UI of BlueGriffon or Postbox in html (and that will imply rewriting most of the js around) for the time being, what do you suggest?

I would like to have a response from - or some direct interaction with - Chris Beard please. Putting XUL to rest would be a death knell on a critically-large part of my business - among others - and I think it deserves a bit more than a technical discussion or one-liners with a smiley. In short, it would kill my company. Long-time partners heavily relying on XUL deserve a bit more than the current ultralight information we have.

Thanks.

</Daniel>

[Bobby Holley]

On Wed, Oct 15, 2014 at 9:40 AM, glazou <daniel....@gmail.com> wrote:

> 1. does Mozilla still care about us?

In terms of the goals of the organization, I think it's pretty clear that
XUL embeddings are not a priority - they're pretty orthogonal to the
Mozilla Mission (which is about the Internet and the Web - not desktop
SDKs).

Lots of Mozilla developers have positive feelings and personal
relationships with embedders like yourself, and so we do our best to make
things smooth when we can. But fundamentally, we would be doing a
disservice to our mission if we spent significant resources on non-web
technologies like XUL. Gecko is large and often unwieldy, so any transition
takes time. But I think it's pretty clear that our _ideal_ direction would
be to migrate all frontend code to standardized non-dead-end technologies
like HTML and WebComponents. This lets us focus our efforts, eat our own
dogfood, and make it easier for web developers to contribute to Firefox.

> I have endlessly tried to discuss the fate of XUL and XULRunner with a
> previous Mozilla CEO, Gary Kovacs. He _never_ accepted to have a chat about
> it.

This isn't really something that a C-level exec would have anything useful
to say about. Bob Moss is the VP of Gecko, but even he would probably defer
to the judgement of the people you're talking to (bz, roc, dbaron,
bsmedberg, myself, etc). And I think our opinions are pretty clear in this
thread.

> I have the feeling we are left outside alone in a « too bad for you » move
> and I find it depressing.
>

I agree that the current state of affairs sucks for XUL embedders, and you
have our sympathy. But if we translate that sympathy into strategy, we will
lose much bigger battles.

> 2. since it's out of question to rebuild something as big as the UI of
> BlueGriffon or Postbox in html (and that will imply rewriting most of the
> js around) for the time being, what do you suggest?
>

Firefox is much bigger than BlueGriffon, and is still mostly written in
XUL. I'd suggest following the same strategy as the Firefox team - slowly
transition to web technology, and file bugs when stuff doesn't work. If you
want to go whole-hog and ride the technologies that Mozilla is investing
in, I'd suggest creating an OpenWebApp that you can put in the Mozilla
Marketplace. If you do that, you will find orders of magnitude more
responsiveness and interest from Mozilla's side than you will as a
XULRunner developer.

> I would like to have a response from - or some direct interaction with -
> Chris Beard please.

I don't set his schedule, but per above I doubt he'd have much to say on
this topic.

bholley

[glazou]

Le mercredi 15 octobre 2014 10:18:19 UTC+2, Bobby Holley a écrit :

> I agree that the current state of affairs sucks for XUL embedders, and you
> have our sympathy. But if we translate that sympathy into strategy, we will
> lose much bigger battles.

I have the feeling "sucks" is a bit far from reality... This is going
to kill long-time partners of Mozilla w/o even trying to discuss with
them the situation, the possibilities, the alternatives, the ETA,
the transition plan. Ahem, to say the least.

> Firefox is much bigger than BlueGriffon, and is still mostly written in
> XUL. I'd suggest following the same strategy as the Firefox team - slowly
> transition to web technology, and file bugs when stuff doesn't work. If you
> want to go whole-hog and ride the technologies that Mozilla is investing
> in, I'd suggest creating an OpenWebApp that you can put in the Mozilla
> Marketplace. If you do that, you will find orders of magnitude more
> responsiveness and interest from Mozilla's side than you will as a
> XULRunner developer.

That will require an enormous investment that most embedders won't be
able to cope with.

</Daniel>

[Boris Zbarsky]

On 10/15/14, 3:40 AM, glazou wrote:
> Guys, you understand there is an ecosystem - even if it is a small one - of companies relying on XUL for their businesses?

Yes, including Mozilla, via Firefox.

> 1. does Mozilla still care about us?

I can't answer this question. On a personal level, I care about you,
but not enough to leave XUL in the tree if you're the only remaining
consumer. Which you're not.

> 2. since it's out of question to rebuild something as big as the UI of BlueGriffon or Postbox in html (and that will imply rewriting most of the js around) for the time being, what do you suggest?

The Firefox UI has the same issue. The only viable plan I can think of
for either case is to move the UI to HTML piecemeal (e.g. move the
preferences dialog into HTML, etc) until the remaining work is small
enough to be done in a flag day.

I'm not saying this is an easy project, or high priority at the moment,
so it's not likely to happen anytime soon, but I believe it _is_
desirable and should be the end goal. At least for Firefox and Gecko.

Whether this happens before Gecko is perhaps replaced by Servo or
something is anyone's guess. Servo doesn't support XUL and has no plans
to, of course.

> I would like to have a response from - or some direct interaction with - Chris Beard please.

This is probably the wrong forum for that; I doubt he reads this newsgroup.

> Long-time partners heavily relying on XUL deserve a bit more than the current ultralight information we have.

There isn't any more information to be had. On the technical level, we
would like to get rid of the complexity XUL support introduces to the
rendering engine. There are no _concrete_ plans or timescales for doing
that, it would be blocked on a whole bunch of other changes at the very
least to Firefox desktop builds, and it's not clear when or whether it
will actually happen.

-Boris

[Boris Zbarsky]

On 10/15/14, 5:01 AM, glazou wrote:
> w/o even trying to discuss with
> them the situation, the possibilities, the alternatives, the ETA,
> the transition plan.

The situation is that we have a bunch of unmaintained code that
complicates layout. And layout needs no extra complications; it has
enough as it is. So again, on a purely technical level we would like to
get rid of this code.

I'm happy to discuss possibilities and alternatives, of course. Any ideas?

There is no ETA, and no concrete transition plan past the one Bobby and
I outlined upthread.

> That will require an enormous investment that most embedders won't be
> able to cope with.

I don't think that long-term (think decades, not years) Mozilla can cope
with the investment of having the XUL support we have in the rendering
engine right now....

-Boris

[Mike de Boer]

This is one of the reasons I started to breathe new life in the Chromeless project[1], but with a grander scope this time around.
I’d like to facilitate a pragmatic migration route to building desktop apps with XULRunner using only the latest Web technologies, including asm.js and WebGL+WebVR.

Due to my work on Australis, Loop/ Hello and the move to a new house eating away my spare time too, this project got stalled quite a bit as I can/ could only work on it then.
I hope to be able to pick up this work again soon!

Perhaps this project offers a likeable middle-ground solution to still allow for a Mozilla SDK to exist, while not needing to maintain the entire XUL stack.

Mike.

[1] https://github.com/mikedeboer/chromeless2

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Boris Zbarsky]

On 10/15/14, 9:03 AM, Boris Zbarsky wrote:
> The situation is that we have a bunch of unmaintained code that
> complicates layout.

I feel like I should expand on this.

"XUL" covers a variety of somewhat-unrelated features, including at least:

1) The XUL box model.
2) The built-in XUL elements (with C++ implementations). <tree> for
example.
3) The overlay system.
4) XBL and the bindings provided by default.
5) Localization via DTDs

I probably missed some; please tell me what they are.

I would dearly like #1 to go away in favor of flexbox. This might be
possible to do without changing anything else, maybe, albeit with some
UI layout breakage in some consumers because the models are not quite
identical. If that's not possible, it might be a good idea to migrate
away from flexbox manually (by using those display types instead of
-moz-box and company in your stylesheets for XUL hbox/vbox/etc
elements). flexbox is all done, pretty much, so there is a viable path
forward here that just needs resources. This would clearly not affect
scripts, except to the extent that the slightly different layout model
forces changes to the DOM used.

I'm slightly less concerned about #2, though it would be good to replace
those with web components if/when possible.

I haven't thought much about #3; it's somewhat in its own little world
and has no web tech equivalent.

For #4 a viable path forward is piecemeal conversion to web components
once those are stable and shipping. Since they aren't, there's nothing
to think about here yet.

For #5, I'm not an expert. l20n or something seems like a possible
replacement, but in any case a replacement would need to exist to talk
about moving away from the current localization mechanism.

Again, except for maybe #1 these are all off in "who knows when this
will be possible?" territory. I'm sorry if you got the impression that
there are short-term plans to remove anything here.

-Boris

[L. David Baron]

On Wednesday 2014-10-15 09:24 -0400, Boris Zbarsky wrote:
> "XUL" covers a variety of somewhat-unrelated features, including at least:
>
> 1) The XUL box model.
> 2) The built-in XUL elements (with C++ implementations). <tree> for
> example.
> 3) The overlay system.
> 4) XBL and the bindings provided by default.
> 5) Localization via DTDs
>
> I probably missed some; please tell me what they are.
>
> I would dearly like #1 to go away in favor of flexbox. This might
> be possible to do without changing anything else, maybe, albeit with
> some UI layout breakage in some consumers because the models are not
> quite identical. If that's not possible, it might be a good idea to
> migrate away from flexbox manually (by using those display types
> instead of -moz-box and company in your stylesheets for XUL
> hbox/vbox/etc elements). flexbox is all done, pretty much, so there
> is a viable path forward here that just needs resources. This would
> clearly not affect scripts, except to the extent that the slightly
> different layout model forces changes to the DOM used.
>
> I'm slightly less concerned about #2, though it would be good to
> replace those with web components if/when possible.
>
> I haven't thought much about #3; it's somewhat in its own little
> world and has no web tech equivalent.

We should also distinguish between doing the work to make things go
away, and putting effort into improving them. For the former, we
have to compare the amount of overhead (over time) these features
add to the amount of work (once) it would take them to go away. But
what started this thread was the latter -- adding new features to
XUL.

Part of the problem with adding features to XUL is that there is not
an effective community around this technology. We don't have code
reviewers who are domain experts in it, and thus code reviews end up
falling to people with general knowledge of all of layout, who are
already overloaded with other work that contributes much more to
Mozilla's mission.

Don't, however, take that as a suggestion that we're looking for
volunteers. I think at this point it's too late; we've had 11 years
since Netscape stopped improving this technology for volunteers to
show up to lead its development. Yes, we have occasional
contributors show up to add a feature that they want. But we don't
have anyone who's leading its development or who has a good reason
to do so. The Web has beaten XUL, and it's part of our mission to
make the Web beat XUL, and other things like it; the Web is open,
standardized, and cross-vendor.

XUL isn't going away anytime soon because we have too many
dependencies on it. Getting rid of it is a long-term goal, not a
short-term one. What we're saying now is that we're not going to
invest effort into mentoring and reviewing additions of features to
XUL -- effort that we could otherwise spend improving the Web.

[Gervase Markham]

On 15/10/14 14:24, Boris Zbarsky wrote:
> I haven't thought much about #3; it's somewhat in its own little world
> and has no web tech equivalent.

Although glazou did propose one a decade ago:
http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html

Gerv

[Neil]

Boris Zbarsky wrote:

> The situation is that we have a bunch of unmaintained code that
> complicates layout.

Out of interest, what does it do that complicates layout? You mentioned
the box model of course, but what else is there?

--
Warning: May contain traces of nuts.

[David Rajchenbach-Teller]

Which actually looks pretty good to me and should perhaps be (re)discussed.

I wonder if something like HTMLoverlays (certainly extended with a
mechanism to help with unloading) could be made part of the Add-on SDK.

Cheers,
David

On 16/10/14 04:53, Gervase Markham wrote:
> Although glazou did propose one a decade ago:
> http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html
>
> Gerv
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[Boris Zbarsky]

On 10/16/14, 5:30 AM, Neil wrote:
> Out of interest, what does it do that complicates layout? You mentioned
> the box model of course, but what else is there?

There's a bunch of listbox-related frame constructor complexity (and for
a while it was a quite lively source of security bugs, too).

But for the most part the layout complications come from the box model, yes.

-Boris

[Ehsan Akhgari]

On 2014-10-16, 7:02 AM, David Rajchenbach-Teller wrote:
> Which actually looks pretty good to me and should perhaps be (re)discussed.

It can be implemented in JS, right?

[David Rajchenbach-Teller]

On 16/10/14 12:54, Ehsan Akhgari wrote:
> It can be implemented in JS, right?

Indeed.

[Ehsan Akhgari]

On 2014-10-16, 1:44 PM, David Rajchenbach-Teller wrote:
> On 16/10/14 12:54, Ehsan Akhgari wrote:
>> It can be implemented in JS, right?
>
> Indeed.

I meant, as a JS library by web developers who feel like it's needed,
not by us. :-)

FWIW I think that XUL overlays are a terrible way of extending the UI so
I'm not in a rush for something like that to happen for HTML. Their
biggest issue is that they completely ignore the problem of how to
handle two different overlays being applied to the same element. They
also effectively make your DOM structure a public API which is barely
maintainable, as we have learned the hard way.

[Gijs Kruitbosch]

There are also "interesting" height computation issues that I'm pretty
sure HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a
function of the box model, considering it's not an issue with flexbox...

~ Gijs

[Robert O'Callahan]

On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch <gijskru...@gmail.com>
wrote:

There are also "interesting" height computation issues that I'm pretty sure
> HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a
> function of the box model, considering it's not an issue with flexbox...
>

Yeah. XUL layout (all layouts, not just flexbox) compute intrinsic width
*and* height bottom up before doing actual layout. This is incompatible
with CSS and really just broken, and the friction between that model and
CSS is painful.

[Yonggang Luo]

There is a lost of falt in XUL, but still have something good, such as tree and the XBL binding, besides, the window elements is also important, because we need it to implement chromeless window, and titlebar, there is no equivalent in HTML/JS, that's must be considerate when propose the removal of XUL.

[Yonggang Luo]

在 2014年10月17日星期五UTC+8下午2时39分54秒，Yonggang Luo写道：

> There is a lost of falt in XUL, but still have something good, such as tree and the XBL binding, besides, the window elements is also important, because we need it to implement chromeless window, and titlebar, there is no equivalent in HTML/JS, that's must be considerate when propose the removal of XUL.

There is also the command liner parser is also needed.

[Gijs Kruitbosch]

On 16/10/2014 13:56, Robert O'Callahan wrote:
> On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch <gijskru...@gmail.com>
> wrote:
>
> There are also "interesting" height computation issues that I'm pretty sure
>> HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a
>> function of the box model, considering it's not an issue with flexbox...
>>
>
> Yeah. XUL layout (all layouts, not just flexbox) compute intrinsic width
> *and* height bottom up before doing actual layout. This is incompatible
> with CSS and really just broken, and the friction between that model and
> CSS is painful.
>
> Rob

This is an interesting point in terms of wanting to switch to HTML here.
We use quite a lot of popups and panels in the Firefox front-end code.
Those size to content (and windows/dialogs have a .sizeToContent
method). How would/could that work in the HTML/CSS model?

(asking particularly because I'd love to have an alternative for the
broken XUL layout we get now which leads to stupid bugs and wasted time
and frustration - so far I've not been able to work around just by using
lots of display: flex; and friends...)

~ Gijs