Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
Unless I'm misunderstanding something, I believe this actually is - or at least touches upon - several questions in disguise: .) Do we want to allow decoration of elements that are already in the DOM tree? - which is for all intents and purposes a corollary of: .) Do we allow calling of new ShadowRoot outside of an element constructor? If no, then we don't have a problem with dead elements, because the author can only declare new elements (and use encapsulation), but not meddle with existing ones. FWIW, I don't think there is any real use-case for calling new ShadowRoot within the constructor twice. However, in this case we have to answer how encapsulation can address the stated use cases for decoration. This probably means answering: .) How is attribute forwarding handled from the host element to a nested (form) element? .) How can components participate in forms (and other fun)? ... or just leave decoration out for the time being (which I think is quite reasonable). OTOH, if the answer to the decorators question is yes, then the above mentioned issues with multiple shadow roots arise.
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Fri, Aug 26, 2011 at 12:24 AM, Roland Steiner rolandstei...@google.com wrote: Unless I'm misunderstanding something, I believe this actually is - or at least touches upon - several questions in disguise: .) Do we want to allow decoration of elements that are already in the DOM tree? If by decoration you mean new ShadowRoot then I think the answer is yes. Why would you disallow it? It throws one more obstacle in the author’s way. - which is for all intents and purposes a corollary of: .) Do we allow calling of new ShadowRoot outside of an element constructor? From the DOM bindings point of view, it is very difficult to decide when a constructor is running. How would you do it? Stack walking? I don’t think any other bindings do this sort of thing. If no, then we don't have a problem with dead elements, because the author can only declare new elements (and use encapsulation), but not meddle with existing ones. FWIW, I don't think there is any real use-case for calling new ShadowRoot within the constructor twice. I take the point that if you can only call it once, and only in constructors, then you can easily assign meaning to new ShadowRoot(x) where x is not an extension element. It throws. But you could just make that restriction without all of these other restrictions on constructors, once only, etc. I don’t want us to confound being able to call it only once or more than once for a given element, being able to call it for extension elements only or built-in element types too, and being able to call it only inside constructors or also outside of constructors. However, in this case we have to answer how encapsulation can address the stated use cases for decoration. This probably means answering: .) How is attribute forwarding handled from the host element to a nested (form) element? +1. We should think about concrete proposals. Also: Do the use cases need it? And if we did nothing, what would authors do in response (ie how ugly are mutation listeners?) .) How can components participate in forms (and other fun)? ... or just leave decoration out for the time being (which I think is quite reasonable). We should brainstorm other fit issues. What about the selection? Does it leak shadow nodes (probably not.) So can confined scripts ever read the selection? etc. OTOH, if the answer to the decorators question is yes, then the above mentioned issues with multiple shadow roots arise. I think we need to think about these issues anyway. But maybe the multiple shadows problem is a good one to tackle early. Dominic
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney domin...@google.com wrote:
On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov dglaz...@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
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 11:57 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? Can you help me understand what you mean by this? What would be a functional difference between the two cases you outlined? Can I push that on the stack until we have use cases? My suspicion is that it will be qualitatively different; if a widget library provides a set of shadows that are designed to work together, the library can manage the complexity of stacking them right. If the author has to get the order right, it will be hard. But without use cases I’m not certain—just a hunch. I have been wracking my brain for use cases. I keep going in two circles though: 1. Sometimes you want to alter the presentation of the element. (Or at least the element’s children—we’ve always just focussed on the element’s children.) But sometimes you want to augment the presentation. Imagine if input type=text did not use shadow, and you want to use shadow to add a very fancy tooltip. That won’t work, because you will obliterate the text in the input element when you add the tooltip. Why does the *first* shadow have such special semantics? 2. You describe multiple shadows as stacking up side-by-side. What about containment? What if I could do this: var shadowA = new ShadowRoot(someElement); // init shadow A var shadowB = new ShadowRoot(shadowA); // init shadow B then shadowB’s content could chew on the flattened tree of shadowA. It can put things side-by-side by putting elements side-by-side with content; it can also put things inside other things by nesting content. (This doesn’t solve your order problem, though.) :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 11:58 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Also -- we can always try to start with just one subtree, and then enable multiple. Since the plumbing and the order specification are trivial, it's something we can easily add. :DG Yes. This sounds like a good plan. If we come up with use cases, we can reevaluate in the light of new ideas. Even if new use cases prove compelling, starting with a single shadow is probably still a good approach anyway. Dominic On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov dglaz...@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
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov dglaz...@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
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? Can you help me understand what you mean by this? What would be a functional difference between the two cases you outlined? :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
Also -- we can always try to start with just one subtree, and then enable multiple. Since the plumbing and the order specification are trivial, it's something we can easily add. :DG On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? :DG -- erik
