W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 28 Nov 2012 14:51:20 -0800
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Elliott Sprehn <esprehn@gmail.com>, Dominic Cooney <dominicc@chromium.org>, public-webapps <public-webapps@w3.org>
Message-id: <792F4BF9-8A74-42A7-A26D-23191CF1A555@apple.com>
To: Dimitri Glazkov <dglazkov@chromium.org>

Does this support the previously discussed mechanism of allowing either public or private components? I'm not able to tell from the referenced sections.

 - Maciej

On Nov 28, 2012, at 1:17 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:

> 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<
> 
Received on Wednesday, 28 November 2012 22:51:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:56 GMT