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:56:36 +0900
Message-ID: <CAHnmYQ-WxxPkwP0U2n6ZmiACEVAEHUc2Ye5Cvh4+KriZi1gXnw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@gmail.com>
On Wed, Feb 27, 2013 at 4:03 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/26/13 1:57 PM, Tab Atkins Jr. wrote:
>
>> 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
>>
>
> I think "ad-hoc" in this case means "per-component", not "ad-hoc method of
> exposing".  The method of exposing should be standardized no matter what; I
> think we agree on that.
>
> -Boris
>

Yes, by “ad-hoc” I meant “per-component.”

If shadows are private by default, maybe it makes sense for the spec to
have commentary about how shadows should be exposed by scripts that want to
expose them.

Alternatively, if shadows are public by default, maybe the spec should have
commentary about not breaking multiple shadows if scripts want to hide
them. (I think there are performance downsides to having public shadow DOM
and hiding it with script, but it probably does not make sense for spec
commentary to venture there.)

One more thought occurs to me: It is easier to add public shadows in a
subsequent revision of the spec than it is to take public shadows away.
Provided the message that Shadow DOM does not provide meaningful security
guarantees is understood, we could consider private Shadow DOM a
conservative initial design.
Received on Tuesday, 26 February 2013 20:57:04 GMT

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