Status of Web Components support in Firefox

This is an experimental technology
Because this technology's specification has not stabilized, check the compatibility table for usage in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future versions of browsers as the specification changes.

Web Components is still a very new technology, its specifications being evolved as browser implementers and Web developers gather experience using it. Its implementation status is variable and evolves quickly; this article lists the status in Gecko, used by Firefox and Firefox OS.

Natively supported

The following features are implemented and activated by default in Firefox and Firefox OS:

Upcoming features

  • An implementation of the new consensus-based Shadow DOM is expected to ship in Q1 2016; Anne's and Wilson's blog posts presents the details. There are still a lot of discussions and open issues on the specification, and all browsers' implementations are expected to be updated in the future.
  • Custom elements are back on the drawing board, with a plan to rebuild them using the ECMAScript 2015 class syntax (that is, to make them less prototype based). Apple's Ryosuke Niwa is fleshing out some experiments to come up with new approaches.
  • There will be a vendor face to face meeting in January 2016 to further discuss these issues.

Abandoned features

These features were considered for implementation, and have some experimental implementation. They will never be implemented, or will be removed.

  • HTML imports, as we want to wait to see what do developers do with ES2015 modules (not implemented yet; see bug 568953). There was an early unfinished implementation of imports which will be removed from Firefox.

Using polyfills with Firefox

There are a few caveats to consider when using polyfills with Firefox:

  • When you activate native Web Components support in Firefox by setting the dom.webcomponents.enabled preference to true in about:config, the incomplete native implementations kick into action and the polyfills might get confused; this has a strong possibility of breaking things.
  • A polyfilled Shadow DOM using the webcomponents.js polyfill doesn't actually encapsulate style, so the styles might bleed through. Be aware that sites built using the polyfill might look different when running in an environment that does support native Shadow DOM.
  • The Shadow DOM polyfill is also very slow as it rewrites the prototypes of DOM elements to hook into their functionality (so it's more of a polyreplace than a polyfill!).
  • If you don't need to use Shadow DOM, it's advisable to use the webcomponents-lite.js version of the webcomponents.js polyfill; this one doesn't polyfill Shadow DOM.

Document Tags and Contributors

 Contributors to this page: kdex, Sheppy, teoli, Sole
 Last updated by: kdex,