Mozilla and Web Components: Update

Editor’s note: Mozilla has a long history of participating in standards development. The post below shows a real-time slice of how standards are debated and adopted. The goal is to update developers who are most affected by implementation decisions we make in Firefox. We are particularly interested in getting feedback from JavaScript library and framework developers.

Mozilla has been working on Web Components — a technology encompassing HTML imports, custom elements, and shadow DOM — for a while now and testing this approach in Gaia, the frontend of Firefox OS. Unfortunately, our feedback into the standards process has not always resulted in the changes required for us to ship Web Components. Therefore we decided to reevaluate our stance with members of the developer community.

We came up with the following tentative plan for shipping Web Components in Firefox and we would really appreciate input from the developer community as we move this forward. Web Components changes a core aspect of the Web Platform and getting it right is important. We believe the way to do that is by having the change be driven by the hard learned lessons from JavaScript library developers.

  • Mozilla will not ship an implementation of HTML Imports. We expect that once JavaScript modules — a feature derived from JavaScript libraries written by the developer community — is shipped, the way we look at this problem will have changed. We have also learned from Gaia and others, that lack of HTML Imports is not a problem as the functionality can easily be provided for with a polyfill if desired.
  • Mozilla will ship an implementation of custom elements. Exposing the lifecycle is a very important aspect for the creation of components. We will work with the standards community to use Symbol-named properties for the callbacks to prevent name collisions. We will also ensure the strategy surrounding subclassing is sound with the latest work on that front in JavaScript and that the callbacks are sufficiently capable to describe the lifecycle of elements or can at least be changed in that direction.
  • Mozilla will ship an implementation of shadow DOM. We think work needs to be done to decouple style isolation from event retargeting to make event delegation possible in frameworks and we would like to ensure distribution is sufficiently extensible beyond Selectors. E.g Gaia would like to see this ability.

Our next steps will be working with the standards community to make these changes happen, making sure there is sufficient test coverage in web-platform-tests, and making sure the specifications become detailed enough to implement from.

So please let us know what you think here in the comments or directly on the public-webapps standards list!

About Anne van Kesteren

Standards person with an interest in privacy & security boundaries, as well as web platform architecture · he/him

More articles by Anne van Kesteren…


  1. Laurentj

    >Mozilla will not ship an implementation of HTML Imports

    HTML imports are not only related to web components. I don’t understand your choice to not implement it. Could you give more details about this decision?

    If it is easy to implement it with a polyfill, why don’t you implement it natively?? It will avoid developers to add one more polyfill script in their webpages.

    December 15th, 2014 at 09:08

    1. 葉至柔


      January 1st, 2015 at 10:54

  2. Ryan Frederick

    At first glance, I’m disappointed by this. Perhaps my take will change as I spend more time with Web Components, but to me HTML imports was a really key feature. ES6 modules are great, but AFAIK they only package JS. Being able to package a web component (template, and all associated assets) and distribute it without further dependencies is not only appealing and convenient but a key factor in making web components as a whole successful.

    I realize that reconciling ES6 modules and HTML imports is likely a necessary step, but I hope that Mozilla eventually reconsiders implementing HTML imports after some consideration and dialogue with the community and other vendors.

    December 15th, 2014 at 09:23

    1. dima

      There is at least one polyfill for that, why would you need it to be shipped with the browser? Do you think it would be so much faster? I don’t think so.

      Also, the polymer project build a tool called “vulcanize”, and it glues all the html pieces together: that would avoid the extra network requests, which are actually the thing that you should avoid.

      December 15th, 2014 at 13:07

      1. laurentj

        a polyfill + an other polyfill + an another polyfill +… Web sites become bloatware because of lack of support of some technologies in some browser.

        It seems that some web developers (and browser developers) don’t tests their web site on mobile in the real life (e.g., with a bad connectivity most of time).

        December 15th, 2014 at 14:33

      2. Ivan

        There is jQuery, why would you need to put ‘native functions’ like querySelector on browsers?

        We could use IE6 + jQuery forever! Whoooooooa…

        jQuery > ALL


        December 16th, 2014 at 04:21

      3. Erik isaksen

        As for vulcanize – my understanding is that once we are all on http2 concatenation will not be as necessary as it is now. In that vein, vulcanize is a temporary but needed fix for now. Maybe I’m missing something but that’s how I see it. Es6 modules have a much different purpose than imports because they only package JS by design. Portability is a very important feature for Web Components.

        December 17th, 2014 at 02:11

      4. Adam

        AFAIK polyfills cannot parallelize downloading of web components, unlike native HTML imports. That’s why they should be implemented natively.

        December 18th, 2014 at 15:44

    2. Erik Isaksen

      I agree that HTML imports are very appealing. It serves a much different purpose than a JS module despite some similarities

      December 17th, 2014 at 02:06

  3. Anne van Kesteren

    Both ES6 modules and service workers open up resource dependency management to web developers. And while ES6 modules is mostly intended for JavaScript, we want to see what kind of dependency systems will be built on these two systems in libraries and frameworks before committing to a standardized design. Especially before committing to one that is not influenced by them.

    December 15th, 2014 at 12:00

    1. Laurentj

      Well, I don’t see how you could store html template inside an ES6 module.

      Creating a web component is interesting if all parts of a web component is inside the same file, to avoid to load several files (so, to have less http requests).

      HTML import allows that. Like XBL did.

      Sorry, I still don’t understand why Mozilla will not ship HTML import, whereas it is implemented .

      December 15th, 2014 at 14:24

    2. Alex Russell

      Anne: SW’s give you the power to hold some requests while you issue others, they also give you a way to inspect responses before a document gets a hold of them (should you, e.g., implement your own HTML parser in JS in the network thread), but it doesn’t do dependency management by any stretch of the imagination and SW-only dep management is always going to be painful.

      You simply can’t compare it to what HTML Imports do. Nor are ES6 modules similar: they require all deps be imported before you start to run code. HTML Imports are vastly faster in many important cases.

      Yes, we need better primitives in the document to describe how loading is actually issued, something that can underpin the ES6 Module and HTML Imports systems for forming, issuing, and ordering requests; but that’s an archaeology project *about* HTML Imports and ES6 modules, not an argument against (or for) either.


      December 17th, 2014 at 17:44

  4. Joern Turner


    i’m extremely pleased to read that Mozilla is considering to move forward with Web Components.

    I agree that HTML imports is not a strict requirement – it can be accomplished by various other techniques though it wouldn’t probably a that big thing to implement.

    Native Shadow DOM would be really great to see in Mozilla – following Chrome’s example here would make an impact on the other vendors i hope. Progress on the related styling issues would be highly welcome.

    Speaking of my own experience with standards bodies (esp. in W3C) i wish the dev team some boldness to also follow your own opinions even if not everything has been settled in the standard. I found it much more effective to draft and implement your own solutions and take them back to the working group as a working example. IMO such an approach often has more impact on the standardisation process than fighting the words.

    December 15th, 2014 at 13:18

  5. pkozlowski_os

    Oh, I’m really happy to see that work on the HTML imports is paused till we get better understanding of how this would play with ES6 modules. I must say that I was feeling very uneasy about the idea of having 2 separate resource / dependency managers in a browser. I’m really convinced that ES6 module loader and HTML imports share some fundamental problems that merit a common solution.

    December 15th, 2014 at 13:58

  6. Dan

    Since Html Imports is a core part of web components, I think you should implement it. I do agree maybe holding off a little while until things are better understood, ie the relation of es6 module loader and html import interaction. The de-dup portion of html imports need some work as that has concerned me of having 10 copies of the same library bundle with each web component and because its from a different url, they don’t get de-duped.

    So yeah we need to reconcile dependency management with a nice solution for both javascript and html. The Polymer project relies heavily on html imports and since it is a spec of web components it should be implemented, but that is not to say you can’t suggest changes to the spec.

    Main point is once the spec is finalized you should honor it. It really sucks having to handle different code just because you browser makers can’t agree.

    Please make it easier on us web dev and try to make each browser the same from a code perspective. Please no browser wars, of this is better and I am just not going to implement this feature, lets get on the same page. Yes its work for you guys but the impact is grand, you browser devs are few compared to the mass of web dev that have to develop with your platform!! So think of us please!!

    December 15th, 2014 at 20:27

  7. Chuck Horton

    I am very disappointed to hear Mozilla is not planning to implement HTML imports. I have been working with Polymer Project and X-Tag using HTML imports extensively. I have found HTML imports very useful in our development process. Please reconsider your decision.

    December 16th, 2014 at 04:43

  8. Zimon Dai

    Glad to see that mozilla’s finally shipping web components to firefox. But I still do NOT think the reasons to not ship HTML imports mentioned in this post could stand. Yeah many features have polyfills. But letting the developers using Polyfills should not the first-choice of a browser developer.

    December 16th, 2014 at 21:04

  9. markg

    You don’t mention HTML Templates, even though they are one of the Web Components standards. Is that because they are already approved?

    December 16th, 2014 at 23:23

    1. Erik Isaksen

      Yes. They are already in FF.

      December 17th, 2014 at 02:25

    2. Anne van Kesteren

      The template element is integrated into HTML proper and therefore not strictly speaking part of Web Components anymore.

      December 17th, 2014 at 08:47

  10. Erik Isaksen

    Although HTML Imports are not required to create components, es6 modules were never meant to do what imports do.

    I think you will find that fragmenting the support of such a feature will only encourage the ‘Package Manger Wars’ to keep going where we have so many Hacky ways of polyfilling this at compile time.

    Imports are key in that they provide an easy way to package your element and distribute it WITHOUT additional dependencies.

    Es6 modules could do some of this but do we, as a community, really want libraries and frameworks to build their own wrappers around this? Es6 was made for JS – it should not be ‘shoe horned’ into injecting CSS and HTML

    December 17th, 2014 at 02:22

    1. Anne van Kesteren

      Eventually we want something standardized. The reason we are not doing HTML Imports as is now, is because we think its design would be quite a bit different if it was informed by what will come out of JavaScript modules, service workers, and exposing parts of HTTP/2 to JavaScript.

      We would like design to work the other way around. We hand web developers the primitives, and they design various compelling libraries and frameworks on top of that. And then we can see about standardizing something a tad higher-level to improve performance and take away some of the burden of having to use libraries.

      December 17th, 2014 at 08:52

      1. Laurentj

        > and exposing parts of HTTP/2 to JavaScript.

        So you want to wait many years before to see if html import is ok or should be improved ? Because, seriously, HTTP/2 is great, but it will take years before the time when it will be supported by the majority of millions of web server. So majority of projects could not use libraries or features that rely on HTTP/2.

        > And then we can see about standardizing

        Ok, you want to see web developers experimenting these new primitives to validate them. But you don’t want to see developers experimenting HTML import (which is, form my point of view, a “primitive” feature). :-/

        Sorry, I don’t agree with you.

        I don’t like the way taken by web technologies : year after years, we loose declaratives programming in favor of imperative programming, whereas in some context, declarative is better than imperative. The web didn’t exist if Tim Barners-Lee invents a kind of JS instead of HTML. It is so easier to understand and write web pages with HTML/CSS rather than with an imperative language…

        December 18th, 2014 at 02:29

        1. BrianC

          > Ok, you want to see web developers experimenting these new primitives to validate them. But you don’t want to see developers experimenting HTML import

          Ah, but nowhere is this sentiment stated in the article. The line “lack of HTML Imports is not a problem as the functionality can easily be provided for with a polyfill if desired” clearly indicates that Mozilla does not discourage (pardon the double negative) others from trying out HTML imports. The whole declarative/imperative + Tim Berners Lee argument is unfortunately a strawman, as it applies little to the subject at hand. This post never advocates for an imperative, JS-based alternative to HTML imports, nor does it advocate es6 modules as an alternative (note that the es6 module syntax is declarative). Neither does the article state that Mozilla will wait “many years” to analyze the status of HTML imports. Indeed, all of the features introduced are within the timespan of next year, so it’s still quite possible that FireFox will have HTML imports if web standards bodies can find some way to reconcile es6 and custom elements with regards to module systems.

          On that note, here’s a question: How would es6 modules and HTML imports interact? Currently, there’s no clear-cut consensus on this issue, but it’s imperative that there is a mutual understanding between both if HTML5 is not to break horribly. As far as I know, HTML5 imports operate on a completely different mechanism from es6 modules, meaning that they can’t interact with the System module loader. At the very least, this poses a problem with regards to imports including modules. How do you handle that if the module loader can’t interop with HTML imports? Currently, no browser vendor has a definitive answer. Despite backing both Polymer (which, contrary to popular opinion, is NOT the reference implementation for web components) and es6 modules, Google doesn’t have any notable strategy for handling the dichotomy between JS modules and HTML imports either.

          …and now I’ve written a load of incoherent blather. While I’d agree that Mozilla and co should work towards offering new web primitives to developers for experimentation, the decision to hold off on HTML imports appears justified when one considers the implications said feature has for modules in the browser.

          December 18th, 2014 at 12:08

        2. Anne van Kesteren

          Perhaps if HTML Imports provided a truly declarative way to component authoring you had a point, but alas, they do not. Script is required either way.

          December 19th, 2014 at 02:27

      2. Adam

        “…its design would be quite a bit different if it was informed by what will come out of JavaScript modules, service workers, and exposing parts of HTTP/2 to JavaScript”

        Sorry, I don’t get this mumbo-jumbo. Could you describe the reasons in simple terms?

        December 18th, 2014 at 15:50

        1. Tyler

          If you want to *eventually* see something standardized and given as a solution then you need to change the language in your blog post, because right now it sounds like you’re saying that you’re talking the ball and going home, WRT HTML Imports.

          In the meantime, consider adding these features you’re uncertain about as -moz- prefixes so that the web community can decide how it should be done through practice.

          December 29th, 2014 at 08:33

  11. Erik Isaksen

    I still think HTML Imports are very important to have in all browsers and they serve a much different purpose than ES6 Modules.

    Thanks to Benjamin Kelly, Software Engineer at Mozilla Corporation, for sending me these two links that further explain the reasoning behind Mozilla’s decision:

    Alex Russel & Daniel Buchman talk about the differences between modules & imports on this twitter thread:

    December 18th, 2014 at 02:16

  12. Steve Albers

    What is the actual problem that is stopping Mozilla from enabling the standard? The quote in the article (“…our feedback into the standards process has not always resulted in the changes required…”) does not inform – can you help us understand the issue with the standard?

    Can you be specific about the JavaScript modules that should be used instead of Web Imports (is this JavaScript code modules?), how they resolve the issues you have with the W3C standard, and when we can expect them to be implemented? Is this going through a standardization process? Any links?


    December 19th, 2014 at 20:52

  13. Shane

    This news about HTML Imports is very disappointing. At my company, we are awaiting the native support of Templates, Custom Elements, Shadow DOM and Imports in Chrome and Firefox before beginning an effort to re-implement a lot of existing applications with Web Components. As far as I knew, you were just about there (dom.webcomponents.enabled). Will the implementation of HTML Imports behind the flag disappear, too?

    We heavily use AMD/Almond.js and CommonJS/Browserify and absolutely do not understand your concerns with ES6 modules and HTML Imports. If anything, HTML Imports can be enhanced when ES6 modules arrive. How can the abstraction of markup, styling, script and resources be any better than ? Firefox is a great browser and you guys are better than suggesting that developers use a polyfill. Please reconsider.

    December 20th, 2014 at 17:15

    1. markg

      Here is some info about problems that need solving with HTML Imports:

      December 22nd, 2014 at 22:48

  14. Brett Zamir

    Somebody following this about HTML Imports not being available, or when it may be available, ought to update the following (e.g., to indicate if available but not on by default):

    December 23rd, 2014 at 13:26

    1. Jean-Yves

      Thanks. I updated both pages, removing it from Firefox 35, indicating there is no plan to have it Firefox in the others.

      December 24th, 2014 at 00:55

  15. SciDeveloper

    No HTML imports? Boo.

    The history of computing is littered with complex dependency management tools. Please lets have some simple primitives that put’s the developer in control – not some over-complex dependency management thingy that second guesses or has complex rules.

    I’m quite happy with the rule that says URL1 != URL2 then not same resource.

    This is simple, obvious and as a developer easy for me to control.

    Anything else will undoubtedly create a whole bunch of unexpected edge cases and mistakes.

    Anything else is a classic case of premature optimisation – let’s not solve yesterdays problems ( mobile performance is rapidly ceasing to become an issue ), at the cost of complicating tomorrows technology.

    December 24th, 2014 at 03:58

  16. Havi Hoffman [Editor]

    @Brett Zamir – thanks for your comment – those docs have been updated by the MDN team. Best, Havi

    December 24th, 2014 at 11:55

  17. markg

    > […] lack of HTML Imports is not a problem as the functionality
    > can easily be provided for with a polyfill if desired.

    Can you suggest a polyfill to use for this? Is it just Google’s webcomponents.js? Or maybe can you suggest something lighter weight.

    December 28th, 2014 at 19:40

  18. dan


    Don’t be jerks and not implement Html Imports, it is a major part of the Web Component standards, does it have possible problems, Yes, can there be confusion on how Es6 module loader and Html Imports work together, Yes.

    So what, Html Imports is a critical part of web components, and having to polyfill just sucks!!!!!!!. Go with the standard and do it. Things always change and at a later date when we figure out how html imports and es6 could work better or if one could replace the other, then implement that.

    DON’T BE THAT GUY/GIRL just because you are not getting your way, we all agree that there is room for improvement in Html Import standard,your points are valid, but you need to implement it anyway!!!!

    By not doing it you are hamstringing the whole Web Components Standard in the first place, Don’t Be Jerks!!

    December 31st, 2014 at 10:10

    1. Anne van Kesteren

      Just to be very clear, “Web Components” is not a standard yet and only Google is currently shipping an implementation of sorts (not quite matching the specifications even). Therefore giving input into the process of “Web Components” becoming a standard is very much appropriate. You don’t get many attempts to do something right on the web.

      January 5th, 2015 at 00:56

      1. dan

        I understand getting it right, but that is one of the main reasons that web standards have been so haphazard. We end up having our own idea of what is right, good, and perfect, and in the end we just do our own implementations, which is different for ie,safari,chrome,firefox, ect. I think it is one thing we need to change, lets shoot for perfection but go ahead and accept something much less, something good enough, but at least a standard across browsers. Sorry for the harsh words, but at least from my stand point, I was planning on Mozilla following Chrome on Web Components because 2 major browser makers, helps push the others to follow suit, now it’s easier for other makers to not implement Web Components. I guess I am just tired of the Browser Wars, you implement this, we implement that, no one meets in the middle, and web devs suffer and have to just deal with it hence the million different js,html, css libraries to fill the gap. This just remindeds me of why I used firefox in the first place way back when IE where the guys who never followed standards and Firefox stood up and said we will and looked an IE as the guys causing the problems.

        Any way I have always liked FF and use it all the time, I am an early adopter going back to the Netscape days, even though I am not using it right now.

        I do realize Web Components are still not a standard yet but it has lots of press as well as Es6 which is not a standard but it looks like most browsers will implement, but that is another problem, taking 5 years or more to make a standard, way to long. It’s tough to get everyone to agree, I get it. But it would be really nice if we can keep the web moving forward and agree on standards as well.

        Sorry for the rant!

        January 5th, 2015 at 07:09

  19. Martijn

    So what are Gaia apps now using then? I see a whole bunch of in there. I wish this was better documented.

    January 5th, 2015 at 08:06

  20. Dominic Chambers

    Hi @Anne van Kesteren, would you be able to comment on this HTML Exports library I came across:

    On another page the Author states:

    “ES6 module HTML import interop is a bit weird, yeah. But they’re conceptually very similar, and it doesn’t take much to make them to play nice together…”

    Are you able to comment as to whether his assertions makes sense or not?

    Secondly, when you say that:

    “…its design would be quite a bit different if it was informed by what will come out of JavaScript modules, service workers, and exposing parts of HTTP/2 to JavaScript”

    Can you provide a more concrete example of what you think that might actually look like, just as an example. Are you, for instance, talking about projects like that allow multi-asset libraries to be developed using ES6 syntax, and which @Guy Bedford even demonstrates could be used to develop web components?

    January 5th, 2015 at 08:11

  21. Steve Albers

    Reading the Mozilla Brick 2.0 documentation – part of the pitch is to “Load related JavaScript, CSS, and HTML dependencies all in one action (HTML Imports)”. The instructions for using Brick read say to use an HTML Import tag!

    I guess Mozilla is going to drop HTML Imports from Brick 2.0?

    January 5th, 2015 at 19:35

    1. markg

      Google’s platform.js (now called webcomponents.js) is part of Brick and will handle the HTML imports with polyfills. I believe.

      January 5th, 2015 at 21:42

      1. Ras Fred

        If HTML Imports are incomplete to the point where Mozilla will not support it, does is make sense that Mozilla is using the HTML Import draft standard for Brick?

        January 5th, 2015 at 23:07

        1. Potch

          It’s funny. While this decision was being made, The Brick project (mostly me at this point), had reached the entirely parallel conclusion to reverse course on the Brick 2.0 direction and switch to a *purely* Custom Elements driven approach. That means no Shadow DOM or HTML Imports. Expect more about that coming soon, but in essence: Brick as a monolithic project is going away, and the individual components will be published as stand-alone Custom Elements that do not require other facets of Web Components to function.

          January 6th, 2015 at 12:48

  22. Ras Fred

    Will ES6 Modules support importing non-JS resources like HTML Imports?

    January 5th, 2015 at 23:08

  23. Ras Fred

    Is this the current status for ES6 Module support in Firefox?

    January 5th, 2015 at 23:13

    1. Anne van Kesteren

      Yes, I believe so.

      January 6th, 2015 at 11:57

  24. Havi Hoffman [Editor]

    Editor’s note: Thanks everyone for your questions and thoughtful comments and responses. The conversation will continue on the public-webapps standards list ( Comments are now closed on this post.

    January 6th, 2015 at 13:20

Comments are closed for this article.