W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Dominic Cooney <dominicc@google.com>
Date: Thu, 25 Aug 2011 15:15:43 +0900
Message-ID: <CAHnmYQ-rahE7H-tcCBcLHEspS5-VrUbimZD+Rt4na27U4rZuaQ@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@chromium.org>
Cc: public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Alex Russell <slightlyoff@google.com>, Erik Arvidsson <arv@google.com>, MarkM Miller <erights@google.com>
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

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

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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC