Trees! I knew I was forgetting something, thank you. Yeah those are things we're going to need some sane replacements for.
AS far as XBL goes, while I suspect it works from HTML documents I think we want to be phasing out use of XBL too for pretty much the same reasons as XUL. Web components seem like an obvious alternative and I understand that they are only preffed off right now. If we can have them work in chrome documents they could be the right replacement. On Mon, Jan 16, 2017 at 1:28 PM, Matthew N. <ma...@mozilla.com> wrote: > 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
