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 06:44:53 +0900
Message-ID: <CAHnmYQ82rU7TMVTraHgszmwiyDhhoqnoCh=v_e6jhw2ge=uuJw@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 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>?

> * 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.”

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

> * 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 Wednesday, 24 August 2011 21:45:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT