Mozilla and the Shadow DOM

We have done some brainstorming internally around what we want out of
Shadow DOM and components in general, between those working on Gaia
(Firefox OS applications) and those working on Platform (Gecko). We
hope to be able to discuss this at the meeting later this month and
also at the Extensible Web Summit that precedes it. And of course on
this list, happy to answer any questions.

For custom elements is
still an accurate summary of where we are at. For shadow DOM I wrote
this summary:

* Layout containment. We hope that evolving further could allow for some
interesting optimizations and hopefully something akin to element
queries or a resize event down the road. (This is basically a feature
of <iframe> that components lack.)

* Declarative shadow DOM. Mostly for performance it would be nice if
the composed tree could be serialized and cached. That way first
render only requires HTML and CSS with JavaScript kicking in at the
end. We reasoned it might not be too hard to add something like
<shadowroot> given our experience with <template>. The only difference
would be that <shadowroot> itself would also not be appended to the
tree and that the DocumentFragment nee ShadowRoot is associated with
"its parent".

* Isolated shadow DOM. This is the idea of having a "DOM worker" so
that instead of ten <iframe>s with ten globals you can have one global
with ten somethings. This would give applications more parallelization
opportunities and would hopefully enable a large number of companies
from moving away of the practice of using cross-origin <script> with
all its security implications.

* Imperative distribution (C). Distribution can already be observed in
many ways through events and selectors. As a first step we should
probably define more precisely when it happens in terms of the event
loop. And then make it imperative. (I was a bit surprised with the
thread that seemed to conclude at
as Ryosuke's proposal seemed like a good minimal API to do this.)

* Making event retargeting opt-in/out (D). I think opt-in (or only
with isolated) would be better and perhaps if the API needs to change
anyway we can do that, but we could probably live with opt-out as
well. When you use shadow DOM to compose, global reasoning about state
and events is a fairly established pattern that we should enable.

* Closed-but-no-sigar (B, E). We're not sure about closed shadow DOM.
With composition/layout you want scripts to be able to go in and out.
(See also event retargeting.) For styling we'd like to see something
better than boundary-piercing. Ideally something akin to
pseudo-elements, but with the ability to put restrictions on the
amount of things they can affect. In Gecko we'll probably experiment
with "closed" in a way similar to Chrome (to get rid of XBL), but
unless we'd go down the isolated shadow DOM route (which seems
unlikely due to the overhead) that will require proprietary technology
that browsers are nowhere near ready to converge on.

* Multiple shadow roots (A). We'd like to retain this feature.
Although it has complexity, we've heard from both Firefox UI and
Firefox OS application developers that the moment your library gets
sophisticated, you want this for extensibility.

(The letters above are for items that are a match on the

With apologies to Dimitri's nails,


Received on Wednesday, 8 April 2015 06:17:55 UTC