Re: Mozilla and the Shadow DOM

Thanks for the feedback! While the iron is hot I went ahead and
created/updated bugs in the tracker.

On Tue, Apr 7, 2015 at 11:17 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> 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 https://wiki.whatwg.org/wiki/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
> http://dev.w3.org/csswg/css-containment/ 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.)
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28440

>
> * 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".
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28441


>
> * 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.
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28442

>
> * 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
> https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0423.html
> as Ryosuke's proposal seemed like a good minimal API to do this.)
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28443 and existing
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429


>
> * 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.
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444

>
> * 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.
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28445


>
> * 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.
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28446

>
> (The letters above are for items that are a match on the
> https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits
> page.)
>
> With apologies to Dimitri's nails,
>

Mmm... Keratin.

:DG<