Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

On Fri, Aug 26, 2011 at 12:24 AM, Roland Steiner
<rolandsteiner@google.com> wrote:
> Unless I'm misunderstanding something, I believe this actually is - or at
> least touches upon - several questions in disguise:
> .) Do we want to allow decoration of elements that are already in the DOM
> tree?

If by "decoration" you mean "new ShadowRoot" then I think the answer
is "yes." Why would you disallow it? It throws one more obstacle in
the author’s way.

> - which is for all intents and purposes a corollary of:
> .) Do we allow calling of "new ShadowRoot" outside of an element
> constructor?

>From the DOM bindings point of view, it is very difficult to decide
when a "constructor" is running. How would you do it? Stack walking? I
don’t think any other bindings do this sort of thing.

> If no, then we don't have a problem with "dead elements", because the author
> can only declare new elements (and use encapsulation), but not meddle with
> existing ones. FWIW, I don't think there is any real use-case for calling
> "new ShadowRoot" within the constructor twice.

I take the point that if you can only call it once, and only in
constructors, then you can easily assign meaning to "new ShadowRoot(x)
where x is not an extension element." It throws. But you could just
make that restriction without all of these other restrictions on
constructors, once only, etc.

I don’t want us to confound being able to call it only once or more
than once for a given element, being able to call it for extension
elements only or built-in element types too, and being able to call it
only inside constructors or also outside of constructors.

> However, in this case we have to answer how encapsulation can address the
> stated use cases for decoration. This probably means answering:
> .) How is attribute forwarding handled from the host element to a nested
> (form) element?

+1. We should think about concrete proposals. Also: Do the use cases
need it? And if we did nothing, what would authors do in response (ie
how ugly are mutation listeners?)

> .) How can components participate in forms (and other fun)?
> ... or just leave decoration out for the time being (which I think is quite
> reasonable).

We should brainstorm other "fit" issues. What about the selection?
Does it leak shadow nodes (probably not.) So can confined scripts ever
read the selection? etc.

> OTOH, if the answer to the decorators question is "yes", then the above
> mentioned issues with multiple shadow roots arise.

I think we need to think about these issues anyway. But maybe the
multiple shadows problem is a good one to tackle early.

Dominic

Received on Friday, 26 August 2011 14:36:30 UTC