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

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Fri, 9 Nov 2012 10:17:39 -0800
Message-ID: <CADh5Ky1=DQ0QFVbMRDcg=92D3Op68kqZYZ=m1_6ukjausDN6Nw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Elliott Sprehn <esprehn@gmail.com>, Dominic Cooney <dominicc@chromium.org>, public-webapps <public-webapps@w3.org>
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 Friday, 9 November 2012 18:18:07 GMT

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