Thanks for your feedback Jaroslav, it's really helpful. The issue around mixing XUL and HTML is one in particular where I think we may end up having to make some platform fixes to at least make the transition away from XUL possible.
On Mon, Jan 16, 2017 at 1:31 PM, Jaroslav Šnajdr <jsna...@gmail.com> wrote: > Hello Dave, > > while contributing to some of the devtools.html refactoring projects, I > noticed the following further issues: > > - the XUL label element has attribute crop=start|center|end, which can be > used to truncate the label text and insert an ellipsis character at the > place of your choice. HTML doesn't have this - ellipsis can be inserted > only at the end, and after doing some RTL magic, also at the start (but not > 100% bug-free). The "center" option is not available at all. Solving this > in CSS would be a really nice addition to the web platform. There's been > some spec work done by Sebastian Zartner few years ago. > > - there is a difference in how events are dispatched in HTML vs XUL > iframes. In HTML, the capture/bubble phases are isolated inside the iframe > window, but in XUL, the target chain crosses the iframe boundaries. This > causes problems for React and its event system, which relies on the HTML > behavior. This can be solved by patching React, or adding a special flag to > the iframe element. > > - when there are elements from both XUL and HTML namespaces inside one XUL > document (happens when doing incremental migration), it can be challenging > to make flex-like layouts work correctly. The standard flex layout and the > XUL flex (-moz-box) interact in ways that are hard to understand. > > Jarda > > > > On Mon, Jan 16, 2017 at 9: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
