W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

From: Dominic Cooney <dominicc@chromium.org>
Date: Wed, 27 Feb 2013 05:47:03 +0900
Message-ID: <CAHnmYQ94c+8e2jJurBrbvtT3HPy=cBXyCmho-sd3bnm6Q1i5iQ@mail.gmail.com>
To: Erik Arvidsson <arv@google.com>
Cc: "Tab Atkins, Jr." <jackalmage@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@gmail.com>, Dimitri Glazkov <dglazkov@chromium.org>
On Wed, Feb 27, 2013 at 4:05 AM, Erik Arvidsson <arv@google.com> wrote:

> Also, if shadows are public by default the API to access the shadow is
> well defined. If shadows are private by default and components decide to
> expose the shadow ad hoc then there is no standardized API.
>
See below.


> On Feb 26, 2013 1:59 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
>> On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney <dominicc@chromium.org>
>> wrote:
>> > Although the default provided by the spec is important, early adopters
>> are
>> > also important in shaping practice. There is apparently strong
>> conviction on
>> > both sides of the argument. If shadows are public by default, there is
>> no
>> > serious obstacle to making them private on an ad-hoc basis; if shadows
>> are
>> > private by default, there is no serious obstacle to making them public
>> on an
>> > ad-hoc basis. Maybe the spec should include non-normative commentary to
>> make
>> > web component authors aware of this choice, and then the
>> "market"/Darwinian
>> > process/etc. will decide.
>>
>> An argument to the contrary (which you do seem to acknowledge later in
>> your message, if I'm reading correctly): if you make shadow private,
>> but allow authors to make them public on an ad-hoc basis, there's no
>> way for tools to reliably access the public shadows.
>
>
Yes, that is what I intended to insinuate in this sentence:

“If shadows are private by default, it would be nice for web component
authors who want public shadows to get them in a way that is consistent and
interoperable especially in the presence of multiple shadows.”


>  This was a
>> problem earlier in the spec, when it was in exactly that state - you
>> got handed your shadow root explicitly, and could, if you wanted,
>> assign it to a public property on your own.  That meant, though, that
>> you could assign it to *any* property, so tools couldn't predict where
>> to look.
>
>
Received on Tuesday, 26 February 2013 20:47:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT