Hi Dave, I am glad that we are having this conversation. To be honest, two of features spinning in Taipei are already partly implemented in HTML, out of the expectations that, dealing with familiar tech means faster development and less regressions. They are
- Desktop video control UI within <video> https://bugzilla.mozilla.org/show_bug.cgi?id=1271765 - The date/time picker to popup from <input type=time> and <input type=date> https://bugzilla.mozilla.org/show_bug.cgi?id=888320 Things are obviously not as perfect as we would have imagined. I would say the outstanding complications learned are the quirks of the XUL embedder. The video control is implemented in HTML but within a XUL anno node. The pickers are implemented in an XHTML embedded inside an xul:panel > xul:iframe. By looking at the patches/follow-up/regressions there you will see how much code would still be live inside XBL (e.g. event forwarding), and one unfortunate layout surprise (bug 1222273). We would need to look at that more broadly to achieve the goal stated. That could even mean re-invest in some XUL layout features if we must. Within HTML, a longer discussion is needed (and intentional decisions outside of HTML features) on how components in HTML should work. Gaia was started in 2011 and became hard to work with quickly due to various reasons, and compartmentalization being one of the biggest. I will stop here as an effort of stop beating the dead horse. DevTools team is using React. We should be ready to make a similar decision when we need to — single-page-web-app needs a committed way of compartmentalization to stay sane, i.e. something (platform feature or not) is needed here to replace XBL. Yeah, the Web Components. I've been hearing about this ever since my employment in Mozilla. Yet, around 2015, I was told the current pref-off implementation will likely be changed as the spec matures so front-end should not build anything on top of it. I don't know if the status has changed but I will personally back away from it before I am given a strong commitment from the platform engineering. Feel free to reach out. Thanks, Tim On Tue, Jan 17, 2017 at 4:43 AM, 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
