> the lack of html rel import in Firefox. Any word if that's ever going to change?
Right now we have no intention of shipping HTML Imports; it's easy to polyfill, and we suspect that implementing ES2015 Modules and the module loader spec will change how we look at the problem of reusable components. To that end, support for a restricted subset of <script type="module"> should land in Firefox Nightly builds tomorrow (https://bugzil.la/1240072), so we're making significant progress on that front.
It may be easy from an internal implementation point of view, but from a usage point of view I disagree, unfortunately. It disallows using static html/css only web-components which strongly goes against the grain of HTML's intent of providing markup only documents. Granted it's a minor use case these days, but it is important to the underlying philosophy of HTML and strongly limits the feasibility of building a static html-only _and_ modular website. Let's say a client's JS is disabled (via NoScript which addons.mozilla.org reports as having 2 million users). In this case it'd completely break html-only web-components for 2 million plus users, even components used primarily for CSS modularity. Unless I'm missing something with how ES2015 modules will work...? This seems like a major lack of support for any notion of custom-components and particularly of user preferences on how they view the web. Which is probably why this seems such (to me) an odd stance for the Firefox developers to take. I'll be following the ES2015 modules to figure out if I'm missing something in this!
Here's an example use case: tailoring static html based documentation with use case based theming. Depending on the clients origin and/or browser type, it'd be trivial to redirect http html-import requests to support various themes/clients. While technically possible without native html-imports, it'd require either JS support or dynamic rewriting of html files (essentially run-time vulcanization on the server) rather than a simple http redirect to a modular component.
> To that end, support for a restricted subset of <script type="module"> should land in Firefox Nightly
It'll be interesting to see how ES2015 Modules and module loader spec eases the day-to-day usage of web-components. Even with polyfills Firefox seems to be difficult to coax into loading custom components -- vulcanizing the html is the only method I've found to be reliable. I'll test drive the <script type="module"> and file any bugs that I might find, thanks for the heads up! The script module should support x-tag library pretty well.
Right now we have no intention of shipping HTML Imports; it's easy to polyfill, and we suspect that implementing ES2015 Modules and the module loader spec will change how we look at the problem of reusable components. To that end, support for a restricted subset of <script type="module"> should land in Firefox Nightly builds tomorrow (https://bugzil.la/1240072), so we're making significant progress on that front.