Anne, Thank you for sharing.
I'm feeling that we might want to divide each feature provided by ShadowDOM
into more fine-grained opt-in/opt-out features, if developers want it.
At the same time, however, I still have a concern, "Do developers really
need such a fine-grained control? Is it too early optimization, isn't?"
I don't have a strong opinion on this. I'd like to hear more feedbacks from
web developers who is making real world UI, like Firefox UI, Firefox OS and
so on.
Currently, most of the features are *hard-coded* in the spec and users
can't customize at all. The concept of "Closed Shadow Trees" is the first
way to customize the feature set, however it still provides a pre-defined
features set.
In summary: (You might want to see the following in monospaced font)
Open Closed
Event Retargeting for a node in:
x x
Deny DOM access, such as element.shadowRoot(), into shadow trees:
x
CSS property values inherits into:
x x
CSS selector doesn't piece into shadow trees:
x x
Special Shadow DOM CSS selector doesn't piece into shadow trees:
x
Filtering a node in event.path() if they are in:
x (This is not spec-ed yet)
Filtering a node in element.getDestinationInsertionPoints() if they are in:
x
..and so on
For example, in the past, event.path() filtered out a node if it's in an
(open) shadow tree, however, I changed it because developers gave us the
feedback that they want to see a node even if it's in a shadow tree.
I expect that the same thing would happen again. It might be difficult for
us to provide a pre-defined set of features which satisfies all
requirements.
Currently, we're going to have two pre-defined sets, open and closed.
Can this two sets satisfy all requirements? I'm not sure.
Other comments inlined,
....
On Wed, Apr 8, 2015 at 3:20 PM Anne van Kesteren <ann...@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.)
>
> * 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".
>
>
I agree. Declarative shadow DOM is a really nice feature. That would make
my life easier. I don't need to write JS to construct a tree of trees in
writing a test casually.
What's more important is that we can serialize/deserialize a tree of trees
by declarative syntax. For example, unless custom elements are used, users
can't copy and paste a piece of the page which uses Shadow DOM. Users will
lose Shadow DOM through copy/paste.
> * 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
> https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0423.html
> 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
> https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits
> page.)
>
> With apologies to Dimitri's nails,
>
>
> --
> https://annevankesteren.nl/
>
>
