Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Tue, Feb 26, 2013 at 2:51 AM, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> On Mon, Feb 25, 2013 at 9:46 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 2/25/13 12:33 PM, Tab Atkins Jr. wrote:
> >>
> >> If a script is explicitly looking inside the shadows of unknown
> >> controls and checking their contents (and then failing when the
> >> unknown control has different contents than whatever it expected),
> >> something is *messed up* with that script.
> >
> >
> > I can 100% guarantee to you that such scripts will get written, will be
> > popular, and will prevent control authors from changing their
> > implementations while preserving the API...
>
> FWIW, I was most ambivalent about this change. I welcome more
> discussion. I know Elliott and Dominic had the strongest opinions on
> this.
>

I think that shadows should be "private." My main concern has been well
represented by Boris; basically, if shadows are not private by default, it
is too easy for pages to come to depend on the internal details of
components, which reduces the value of Web Components.

My thinking on this issue has evolved slightly. These points might be
useful to consider; I did not see them covered elsewhere in this thread yet:

There are a set of use cases, for example Readability, AdBlock,
accessibility tools and debugging tools, that should have access to
shadows. These use cases are mostly handled by browser extensions (or
integration into the browser in the case of debugging tools or Readability
in Safari.) As such, I don’t think these use cases are persuasive arguments
for making shadows public; extensions can have a special means of access.

I think it is preferable to chose to make shadows public, or to make them
private, to having a "mode" that components can opt into.

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.

If shadows are public by default, it would be nice for web component
authors who want private shadows to get them in a way that is reasonably
efficient and is not disruptive in the presence of multiple shadows. It
would be nice if there was at least one high-quality JavaScript library
that came into wide use for this.

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. It would be
nice if there was at least one high-quality JavaScript library that came
into wide use for this.

Dominic