On 1/16/2017 2:43 PM, Dave Townsend wrote:
One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:
* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.
The necessary first step of reducing XUL use is to stop adding any more UI
that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?
Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:
* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.
What other features do we depend on in XUL that I haven't listed?
XUL trees are probably the most complex feature that HTML doesn't have.
Some of its features that I consider important include the use of an
nsITreeView-like generative interface, advanced styling capabilities
(you can style rows/cells based on content, effectively), lazy loading
(in particular, data for child elements isn't asked for until their
parents are expanded). There's also probably performance aspects and
accessibility factors that don't normally feature in the minds of
developers.
XUL overlays and XBL widgets are also things that are likely to be
missed, although Web Components probably largely covers the same feature
space (I don't know enough to know what is missing).
The final point I would make is that we probably need to pick a standard
widget toolkit. I believe in the past, we were shipping 4 different
versions of jQuery because every little frontend silo was importing it
locally for their own needs. Particularly if we need to reimplement
major widgets like <xul:tree>, it makes much more sense to have one
shared implementation that can be collaboratively improved. And put it
in toolkit/, please, not browser/. :-)
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
