Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

As of http://dvcs.w3.org/hg/webcomponents/rev/0714c60f265d, there's now an
API to traverse the shadow trees:

http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#api-shadow-aware-shadow-root
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#api-html-shadow-element-older-shadow-root

Please let me know if I goofed anything up. File bugs or yell at me.

:DG<


On Fri, Nov 9, 2012 at 10:17 AM, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 11/8/12 9:28 AM, Elliott Sprehn wrote:
> >>
> >> If you're worried about malicious attacks on your widget, shadows being
> >> private is not enough. You need a whole new scripting context.
> >
> > Er... yes, you do.  Do widgets not get that?  If not, that's pretty
> > broken...
>
> Having a separate scripting context is certainly useful for a certain
> class of widgets (see Like/+1 button discussion).  That's why we have
> this whole notion of the "isolated" shadow trees. This is also a
> fundamental requirement for enabling UA controls to be built with
> script (I _just_ had a discussion with a fellow WebKit engineer who
> asked for that).
>
> However, for a large class of use cases, mostly represented by the
> libraries/frameworks, the separate scripting context is an unnecessary
> barrier. Libraries like bootstrap, quickui, and x-tags are eager to
> start using shadow DOM to delineate lightweight, purely functional
> boundaries between composable bits in the same document. For these
> developers, where things like:
> a) examining (and sometimes modifying), say a currently selected tab
> in an tab manager;
> b) having a central state stored in the document;
> c) nesting and reusing bits across different libraries;
> are all expected and counted upon. Adding a scripting context boundary
> here is just a "WTF!" stumbling block.
>
> :DG<
>