Trees are the big thing that come to mind. I've heard about three non-XUL re-implementations (IIRC mostly in devtools) which sounds like a maintainability issue and potentially redundancy. I would rather keep using XUL trees than have even more different tree implementations (though I'd be fine with a one or two simpler replacements since many uses of a xul:tree don't need a lot of the feature like nesting) which brings me to my next point:
What about XBL? Does it just work from XHTML documents? Is our implementation of Web Components ready to replace it and riding the trains? I think it would be good to implement drop-in replacements (or as close as possible) for some simple XBL bindings or native XUL elements to prove that Web Components are a replacement. Once the Web Component version is working we can transition to it everywhere. Perhaps something like <preference> would be a good candidate. Matthew On Mon, Jan 16, 2017 at 12:43 PM, Dave Townsend <dtowns...@mozilla.com> 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? > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
