On Thu, Aug 25, 2011 at 11:58 AM, Dimitri Glazkov <[email protected]> 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 <[email protected]> wrote: >> On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov <[email protected]> >> wrote: >>> On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson <[email protected]> wrote: >>>> On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov <[email protected]> >>>> 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 >>>> >>> >> >
