Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

Traversable shadows are a requirement for a number of things like:

- Generic page level libraries and polyfills that need to transform DOM
nodes
- Generic event handling libraries (ex. Pointer events)
- Creating screenshots of the page by rendering every node to a canvas (ex.
Google Feedback)
- Creating awesome bookmarklets like Readability

In our discussions with widget authors we'd either end up making shadows
exposed by convention on almost all widget libraries under a common name as
authors expect to be able to drop in libraries, polyfills and tools like
Feedback, or we'd end up with awful hacks like overriding ShadowRoot or
document.createElement.

querySelector and friends will still stop at these boundaries, so you would
never accidentally fall down into a ShadowRoot. That means that I doubt
you'll get widgets being broken as Boris suggests because people aren't
going to accidentally modify the inside of your widget.

I'd also hate to prevent future innovation like Google Feedback which has
turned out to be a critical component for Google product success. I can't
share specific numbers, but it's had a very high impact and being able to
be dropped into existing pages and just work was fundamental to that. While
perhaps we can eventually solve that use case better, who knows what future
ideas people will come up with.

- E


On Tue, Nov 6, 2012 at 3:44 PM, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> On Thu, Nov 1, 2012 at 9:02 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 11/1/12 7:41 AM, Tab Atkins Jr. wrote:
> >>
> >> There was no good *reason* to be private by default
> >
> >
> > Yes, there was.  It makes it much simpler to author non-buggy components.
> > Most component authors don't really contemplate how their code will
> behave
> > if someone violates the invariants they're depending on in their shadow
> > DOMs.  We've run into this again and again with XBL.
> >
> > So pretty much any component that has a shadow DOM people can mess with
> but
> > doesn't explicitly consider that it can happen is likely to be very
> broken.
> > Depending on what exactly it does, the brokenness can be more or less
> > benign, ranging from "doesn't render right" to "leaks private user data
> to
> > the world".
> >
> >
> >> As a general rule, we should favor being public over
> >> being private unless there's a good privacy or security reason to be
> >> private.
> >
> >
> > As a general rule we should be making it as easy as possible to write
> > non-buggy code, while still allowing flexibility.  In my opinion.
>
> This has been my concern as well.
>
> The story that made me sway is the elementFromPoint story. It goes
> like this: we had an engineer come by and ask to add elementFromPoint
> to ShadowRoot API.
>
> ... this is a short story with a happy ending
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=18912), since
> ShadowRoot hasn't shipped anywhere yet. However, imagine all browsers
> ship Shadow DOM (oh glorious time), and there's a new cool DOM thing
> that we haven't thought of yet. Without ability to get into shadow
> trees and polyfill, we'll quickly see people throw nasty hacks at the
> problem, like they always do (see one that Dominic suggested here:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15409#c5). And that
> seems like a bad smell.
>
> I am both excited and terrified.
>
> Excited, because discovering Angelina Farro's talk
> (http://www.youtube.com/watch?v=JNjnv-Gcpnw) makes me realize that
> this Web Components thing is starting to catch on.
>
> Terrified, because we gotta get this right. The Web is traditionally
> very monkey-patchey and pliable and our strides to make the boundaries
> hard will just breed perversion.
>
> Anyhow. Elliott has made several passionate arguments for travsersable
> shadow trees in person. Maybe he'll have a chance to chime in here.
>
>
> :DG<
>