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

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 25 Feb 2013 09:33:04 -0800
Message-ID: <CAAWBYDDJRibEae1N06Xt2qWKPqn6Pgi6q89G9O+L9r+m5v8pCg@mail.gmail.com>
To: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Cc: public-webapps <public-webapps@w3.org>
On Mon, Feb 25, 2013 at 7:53 AM, Bronislav Klučka
<Bronislav.Klucka@bauglir.com> wrote:
> I'd like to second that, shadow DOM is explicitly designed not to be
> accessible from outside, to stay consistent, to be sure that nothing gets
> broken by altering the internals of Shadow DOM control/widget. I'd like to
> be able to create controls in the future and give those controls to users to
> place them anywhere. I do not want to hear "our site is broken, because
> something else on our page was checking if there's a DIV there and you
> changed it to SECTION, you suck!", internals of the controls should stay
> internals of the control. You are effectively crippling half of the
> advantage of Shadow DOM: the ability do whatever I want to do inside the
> control as long as I expose the same API between versions.

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.

You don't just accidentally see the insides of shadows.  All the
traditional movement and search APIs skip them.  I don't think this is
a realistic fear (not to say it won't happen somewhere, sometime - the
web is big, and people tile the possibility space, including all the
bad ideas).

> So if this is going to be breached, there should be a way for control
> authors to decide, whether they want to opt for this traversing or not...

There is.

Received on Monday, 25 February 2013 17:33:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC