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

On Thu, Aug 25, 2011 at 11:57 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney <dominicc@google.com> wrote:
>> On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>>> On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson <arv@chromium.org> wrote:
>>>> On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov <dglazkov@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
>>>>
>>>
>>
>

Received on Thursday, 25 August 2011 06:52:57 UTC