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

On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> 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.

Got it.

Note that component authors could permit extension in a controlled way
by including an instance of a trivial component within the larger
component with simple composition, and then expose _that_ element’s
shadow root. That would permit "multiple shadows" within a component.

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

If we decide that the element should always be presented, then the
built-in shadow DOM could include a trivial descendant element that is
the extension point. When the script requests a shadow root for the
component, it is commuted and gets a shadow root for the extension
point.

If we decide that it is OK to suppress the presentation of the
component, then we could imagine that these elements capture a
reference to their built-in shadow root and use that. When the script
requests a shadow root for the component, the element’s shadow is
replaced. The implementation of the element continues to consult its
captured shadow.

>> 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?

There are two kinds of "dead"—dead on arrival, like <input>,
<textarea>; elements that you know by looking at the tag name that can
not have shadow (at least in a given implementation) because it uses a
shadow.

Then there are newlydeads, like:

function FooElement() {
  // "super" initialization etc.
  // not dead here
  var shadow = new ShadowRoot(this);
  // 'this' is newly dead to extension via new ShadowRoot at this point
}

Making <input>, <textarea> etc support shadows means nothing is DOA;
permitting multiple shadows means there are no newlydeads
either—nothing is ever dead.

Dominic

> :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 06:16:09 UTC