On Mon, Jan 16, 2017 at 1:33 PM, Mike Connor <mcon...@mozilla.com> wrote:
> I think the rule is fine, subject to the reality that the scope of totally > new doc-level UX is fairly limited. I think you'll want to be a little > more aggressive up front if you want to shift the overall codebase in > finite time. > > To that end, I'd propose an additional requirement that any major refactor > or redesign of in-content or separate-window UI (i.e. I've heard rumblings > of a pending preferences redesign) should move to HTML if possible. If > it's not possible, the relevant issues should be filed and tracked as a > condition of waiving the refactor requirement. (I think it's a module > owner call whether to waive, since getting off XUL is likely going to > matter more in another year or two.) > Yeah that makes a lot of sense. Of course as with any rule we make I expect there to be small cases where we have to waive at least at first. On your bullet points, I think the main blocker to moving everything to at > least mostly-HTML outside of browser.xul is going to be the top-level menu > issue. That might be a good test case for a new Web Component binding, to > follow on from MattN's thinking. > > -- Mike > > On Mon, Jan 16, 2017 at 3: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
