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: Sun, 24 Feb 2013 21:11:35 -0800
Message-ID: <CAAWBYDB+YZu6TrLR2DX9GQcLTru+pfVzEOGeLWYt_qWdfnKyfQ@mail.gmail.com>
To: Blake Kaplan <mrbkap@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
On Thu, Feb 21, 2013 at 6:33 PM, Blake Kaplan <mrbkap@gmail.com> wrote:
> Hello everybody,
> I'm coming into this conversation late, but wanted to add my thoughts.
> As has been pointed out in this thread, the web has traditionally been
> very open and malleable. JavaScript has very few readonly properties,
> doesn't generally throw exceptions instead guessing or returning bogus
> values. Making shadow trees hidden clearly goes against this idiom
> and, by definition, limits what pages will be able to do with external
> libraries built using shadow DOMs.
> Even given this downside, though, I think that it's a mistake to make
> shadow trees accessible to the bound document by default. One of the
> most important features for frameworks is the ability to provide an
> encapsulated API. Without that, it becomes extremely difficult to fix
> bugs or add features to the framework without risking breaking
> downstream clients. Shadow DOMs are one of a host of features being
> designed and implemented that make HTML + CSS + JavaScript usable for
> programming in the wild and it feels like an oversight to make the
> default imitate the bad ol' days of monkey patching and low to no
> encapsulation.
> Finally, reading through the thread, it seems like one of the main
> use-cases for open-by-default is features like Google Feedback. From
> my point of view, it seems like features like that need to be
> considered from the beginning of a site's design. So if a site wants
> to have something like GF and also use web components and shadow DOMs,
> then the designers of the components should have to explicitly set the
> bit that says "let other people poke at my internals." I don't think
> that this one use-case needs to trump the good programming practices
> of every other library.

We've gone back and forth.  It seems that allowing monkeypatching by
default is the better choice, as most uses aren't security conscious,
they just want the encapsulation benefits.  If you are doing something
security-conscious, you'd better be thinking about it a bit, and it's
trivial to hide your shadow then.

Google Feedback is merely one particular example of a whole class of
things that *do* want to know the "real DOM" of the page, and which
are fine to allow by default.

Received on Monday, 25 February 2013 05:12:22 UTC

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