A few things we had to handle when going through this process for the devtools UI: 1) Already mentioned to but for panels we added a new module that falls back to XUL panels for now 2) For context menu handling we we added a new module similar to the Menu API from Electron that falls back to <menu> and <menupopup> elements. We didn't need to worry about top-level menus or overlays though. 3) Not impossible but needed a replacement for <key> / <command> elements for registering keyboard shortcuts. 4) Not impossible but agree with Jarda about mixing XUL and HTML flex - many of the bugs blocking the de-XUL meta (https://bugzilla.mozilla.org/show_bug.cgi?id=1263741) were layout issues created when an individual UI component was converted, and finding workarounds can be time consuming and require trial and error.
For 1 and 2, in our case it was worth changing the frontend to use new modules even though they are ultimately still relying on XUL. That let us provide an HTML shim when running the panel in a content tab, and hopefully will let us change the implementation if/when there are ways to do it without XUL. Brian > On 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
