<div dir="ltr">On Wed, Mar 28, 2018 at 5:26 PM, Eric Shepherd (Sheppy) wrote:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Do we have a good handle on what things remote XUL allowed that still can't<br>readily be accomplished using open APIs, HTML, and CSS? We should be sure<br>we know what remains to be done in order to make a complete transition away<br>from XUL possible for anyone still relying on it. I don't know what the<br>prioritization is for actually implementing those features, but knowing<br>what they are would be a necessary first step.<br></blockquote><div><br></div><div>I can give some insight from our perspective, though other Remote XUL consumers may have used things that we didn't, so this list is hardly comprehensive.<br><br></div><div>1) XBL.<br>This was the one thing that kept us on Remote XUL for so long. We created complex XBL widgets, and wanted a robust client-side component technology to migrate to. Web Components is the obvious answer, but still not native in Firefox. Using a polyfill works, but performance is bad for nested Web Components, and the lack of true CSS and event encapsulation has resulted in more complex and ugly code than we would otherwise need.<br><br><br></div><div>2) XUL overlays.<br>We've reimplemented this with some JS of our own to achieve a similar effect, but it was a right pain to do so and performance isn't as good as a native solution. I doubt most other Remote XUL consumers are using these, though.<br><br><br></div><div>3) XUL Trees<br></div><div>We really only used these as flat tables, rather than genuine trees, but even with that restricted use case, HTML tables don't really cut the mustard. XUL trees have column headers that remain fixed in place when you scroll vertically, sortable columns, and reorderable/resizeable columns. Reimplementing these features in HTML is possible, but not at all easy (I believe the pieces are in place, spec-wise, for fixed headers and sortable columns - but no browser seems to support them). I ended up creating a complex Web Component with two tables (one for the column headers, one for the body), synchronised with scroll event handlers (not good...) and a lot of additional code to try to handle column moving and resizing.<br><br></div><div>I would guess that most other XUL consumers used these as real trees, which adds a whole other level of complexity, especially as there's a good chance they're using templates and RDF (yet another level of madness and frustration!).<br><br><br></div><div>4) XUL Tabpanels<br></div><div>Achievable in HTML, but it would be nice to have a simpler component rather than having to roll your own with suitably styled divs and buttons/links and JS to link it all together. These are a common source of z-index problems as the active "tab" needs to be brought to the front, but not appear above any popups or lightbox-style dialogs (which may not even emanate from within the tabbox).<br></div><div><br></div><div><br></div><div>5) XUL Menubars<br></div><div>Again, nothing that can't be done in HTML with enough effort, but there's a world of difference between creating a menubar (with nested submenus) using a little declarative markup, and trying to roll your own in a Web Component.<br><br><br></div><div>6) XUL Popups<br></div><div>Creating a popup or lightbox that can be relied on to appear above everything else in your HTML page is a pain. We all know that just giving something a huge z-index only works on simple pages without positioned elements. In XUL you can just have a <popup>, then tell it to open with a variety of options (too many?) as to where it appears relative to the page, the pointer, or another element - knowing it will always appear on top of everything else, regardless of the structure of your page.<br></div><div><br><br></div><div><rant><br>The common thing about 3-6 is that they are widgets that are frequently used in desktop applications, but have never been implemented as native HTML elements. This has always seemed ludicrous to me, as HTML takes on ever more "application" roles. I hate to think how many developer hours have been lost to proprietary implementations of tab boxes alone, few of which will have all the keyboard handling and other benefits of a native implementation. I understand the desire not to keep adding more and more elements to HTML, but these are UI stalwarts that have been in use for decades - I think they've proven their worth!<br></rant><br></div><div><br></div><div>Most other things I think are reasonably straightforward in HTML, CSS and JS now, especially with flexbox and grid support in CSS.<br><br><br></div><div>The fundamental issue isn't that things *can't* now be done using HTML/CSS/JS, but that doing so is hard, and leads to less than satisfactory results. We've struggled with things like keyboard handling in Web Components, for example, which really hinders accessibility. It can be done, but it takes a huge amount of developer time: consider the implications of writing good keyboard handling code for menus, compared with just being able to add a <menu> tag to your markup.<br><br></div><div>The obvious answer would be for Mozilla to produce some "official" Web Components to replace the more complex XUL widgets. Every component library I've seen focuses mainly on the simplistic cases, such as buttons and fields. If they deal with menus, tables and trees at all the resultant components tend to end up strongly tied to the rest of the library, in style or usage, without the near-native appearance and behaviour of XUL widgets, and without the flexibility to just drop them into a web page which *isn't* using React (or whichever other JS lib the component library is tied to).<br><br></div><div>Parity with Chrome on native Web Components would be a huge win, as it might encourage development of more complex component libraries - or at least some standardisation on best practices - but that's probably not what the original question was getting at. Excuse my frustration: I know native Web Components are on their way... but they've been on the way for many years now, and the end of Remote XUL has made them all the more necessary.<br></div><div><br></div><div><br></div><div>Mark Crutch<br></div><div>Two Fold Software<br><br></div></div>