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

On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney <dominicc@google.com> wrote:
> On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>> All,
>>
>> Adam raises an interesting question: should we allow more than one
>> shadow DOM subtree per element?
>>
>> Background: per current design
>> (http://wiki.whatwg.org/wiki/Component_Model#Encapsulation), you can
>> only create one ShadowRoot instance per element.
>>
>> The reasoning behind this goes like this:
>> * The use cases for adding an extra shadow DOM subtree for built-in
>> elements seemed like hacks around existing limitations of the
>> elements;
>> * We give leverage to elements, allowing them to control whether their
>> shadow DOM subtrees can be extended. If the element exposes its shadow
>> subtree, then yes you can. If it don't then no you can't.
>
> What is the benefit of this leverage? Secure presentation of <input
> type="file">? Sane editing model for <textarea>?

No, this isn't for built-in controls. If Bob builds a Foo element, he
may decide to give it a Foo.shadow accessor to let anyone muck with
its shadow DOM. That's the situation I was talking about.

>
>> * Multiple shadow DOM subtrees introduce the problem of ordering,
>> where the order of rendering these trees is unknowable at the time of
>> creation, which seems like a bad thing.
>>
>> Folks who worked on this with me, I am sure I am missing a couple of
>> things here -- please chime in.
>>
>> However, allowing multiple subtrees certainly has benefits:
>> * No more explicit dead-list of elements that can't have a shadow DOM.
>> You can just create another one.
>
> This problem could be tackled without the complexity of multiple
> shadows by reducing the dead-list to zero, by defining how a shadow
> would work with <input>, <textarea>, … any HTML element we hitherto
> thought would be “dead.”

How would you do that? I am curious. If input element creates a shadow
DOM when constructed, it can't have a shadow DOM. How can we make it
work with shadow DOM?

>
> Or do you mean dead-list of instances of elements, not dead-list of
> kinds of elements?

I think you lost me here -- can you explain?

:DG<

>
>> * More freedom for extending elements (yes, this is the opposite of
>> the single-tree control benefit above)
>>
>> Concept-wise:
>> * Multiple shadow subtrees would just be a list.
>> * The order of a list is established once and is unchangeable. How it
>> is established? I have no idea.
>> * The trees are rendered sequentially (in list order) as if they are
>> children of the hosting element.
>>
>> Security-wise, I don't see any issues off hand.
>>
>> Plumbing-wise, adding support for multiple shadow subtrees should be
>> fairly simple, provided that we solve the order problem.
>>
>> What do you think?
>>
>> :DG<
>>
>

Received on Thursday, 25 August 2011 02:55:42 UTC