W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Mozilla and the Shadow DOM

From: Dimitri Glazkov <dglazkov@google.com>
Date: Thu, 16 Apr 2015 09:46:34 -0700
Message-ID: <CADh5Ky04qHigQAvzHYd2B3fJSX37MN4qgaQWSiyFnzZpVTyYQg@mail.gmail.com>
To: Wilson Page <wilsonpage@me.com>
Cc: Elliott Sprehn <esprehn@chromium.org>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
Updated https://www.w3.org/Bugs/Public/show_bug.cgi?id=28446 with the
latest, to keep the history in bug.

:DG<

On Thu, Apr 16, 2015 at 7:52 AM, Dimitri Glazkov <dglazkov@google.com>
wrote:

> On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page <wilsonpage@me.com> wrote:
>
>> This is an interesting approach that didn't occur to me! Similar to
>> Anne's concerns, this would require you to have more knowledge of the
>> internals of the super-class component. If you own both components then
>> this is fine.
>>
>
> Yes, the main problem here is the degree of separation between creator and
> consumer of the base component. The higher the degree, the less inclined
> the creator will be to expose innards of the shadow tree to the consumer.
>
> Multiple shadow roots solves the same problem as shadow trees (provides a
> composition contract), but along the inheritance chain.
>
> For example, multiple shadow roots make sense:
>
> * if you are a maker of UI library that's strongly rooted in inheritance
> and intend to for your base components to be used directly;
>
> * if you are hoping to inherit from components with closed shadow trees.
>
>
>> Also if this means we can remove a complex piece from the spec to help
>> reach consensus, great! :)
>>
>
> Whatever it takes.
>
> :DG<
>
Received on Thursday, 16 April 2015 16:47:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC