desktop e-mail UI using gaia e-mail libs (was: TB and AMO...)
asutherland at asutherland.org
Mon Oct 28 03:16:31 UTC 2013
On 10/27/2013 09:59 AM, neandr at gmx.de wrote:
> Very clear if MoCo is moving more and more to JS/HTML/CSS based
> technique the XUL will become obsolete. From the perspective of a
> contributor for legacy add-ons (written with XUL) this is an important
> point for future offerings.
I wouldn't call it a MoCo thing, more a Firefox/Gecko thing and a marked
increase in the capabilities of HTML for UI layout purposes (both
functionally and from a performance perspective). Neither XUL nor XBL
will ever be a web standard. It makes sense to build Firefox's UI using
web standards technologies to the maximum extent possible, both for
philosophical and pragmatic reasons (less code, better performance).
The web standards version of XBL which is half of what powers XUL is the
Web Components effort (http://www.w3.org/TR/components-intro/). The
other half of XUL is native C++ code, some of which is layout stuff
related to moz-box that is obsoleted by CSS3 flexbox
Web Components in conjunction with the flexbox stuff can be made to do
everything XUL does.
The main question is whether anyone would undertake a direct
porting/re-implementation of XUL or whether they would create something
new that takes what Firefox actually needs/wants from XUL. My guess
would be the Firefox team would not pursue porting XUL, especially since
HTML5 has subsumed some of the essentials XUL provides (ex: HTML5
but it would not surprise me if there was a community effort to do so.
Alternatively, a lot of XUL could probably be mapped onto existing HTML5
elements or new WebComponents bindings using XSLT, etc.
> Any ideas about plans of the XUL lifetime?
I think XUL will last for a looong time, but like you, I think it will
be used less and less within Firefox proper. Since XUL can no longer be
used for internet pages unless manually whitelisted, it's then really a
question of when the maintenance burden of the XBL and XUL C++ code
becomes too much of a hassle and it is removed from Gecko. I think it
can easily live on via web components if someone steps up to do that.
(And I think that's much more tractable than trying to maintain the C++
code in comm-central, etc.)
In general, I wouldn't worry about it. Web Components are still under
heavy development and there is XUL even in Firefox OS. It will be quite
some time before anyone can begin to propose removing XUL with any
seriousness. (And when they do, it will probably turn out there are
another 10 fundamental things that depend on it!)
More information about the tb-planning