Re: [webcomponents] Making the shadow root an Element

Thank you for enumerating the list, Jonas!

On Thu, Feb 14, 2013 at 11:12 PM, Jonas Sicking <jonas@sicking.cc> wrote:

>
> I chatted with Blake about this today and had some thoughts.
>
> There is definitely no simple answer here, feels like using either an
> Element or a DocumentFragment has some crappy behavior. So it's a
> matter of choosing the less crappy option.
>
> Pros of using a DocumentFragment:
> * Neatly solves the problem of what to do if someone attempts to
> insert the shadow root as a child somewhere. If the root is an Element
> we have to choose between the Element suddenly no longer being a
> shadow root, or throwing.

+1

> * Avoids the problem of what to do if someone sets a style attribute
> on the shadow root, or otherwise attempts to style it. Currently the
> shadow root doesn't appear in the flattened tree (though we could
> maybe change that) which means that it can't be styled. This is
> intuitive if the shadow root is a DocumentFragment but not so much if
> it is an Element.

We will have this problem with other elements as soon as there's
"display: contents"  is implemented.

Also, if ShadowRoot is an Element with UA style of "display:contents",
it still useful for styling (child text nodes, for example),  even
though its box isn't rendered.

>
> Pros of using an Element:
> * Does mean that a lot of code which is used to dealing with just
> Elements and Text nodes will "just work". For example jQuery code
> freaked out [1] over hitting a node that wasn't an Element but still
> had an innerHTML property. There will likely be other code that does
> the same.

We were thinking of adding innerHTML to DocumentFragments anyway... right, Anne?

> * Means that you can set attributes on the shadow root. Again, this is
> likely something libraries will do as they walk around in subtrees.
> Especially if they weren't written with the existence of shadow trees
> in mind (i.e. all the time).

I don't know if this is a pro. The attributes are pretty meaningless
on a shadow root.

> * More consistent with the current types of Nodes that exist.
> Currently people expect all Text, Comment and DocumentFragments to
> have the same API, while Elements have different APIs depending on
> their name. (Documents are somewhere in between as we try to move them
> to the first category, PIs and DocTypes can be ignored for most
> intents). Adding API to *some* DocumentFragment will likely mean that
> people will need to check just what type of DocumentFragment they
> have. Again, see [1] for an example, there will be more as time
> passes.

+1

>
> [1] http://bugs.jquery.com/ticket/13342
>
> Note that the styling issue can be resolved either way. We could make
> the shadow root an Element and insert it into the flattened tree, with
> the default display-box value being "children". Or we could keep the
> shadow root as a DocumentFragment and add a pseduo element like
> ::shadow-root, which lives between an element and its shadow contents.

I agree. The "display:contents" solution seemed more elegant from CSS
perspective, because it describes how a shadow root should behave
pretty well. But in the DOM world, it's a toss, with slight advantage
to DocumentFragment, in my opinion.

:DG<

Received on Saturday, 16 February 2013 17:24:18 UTC