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

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.
* 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.
* 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 17:44:59 UTC