- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Fri, 9 Nov 2012 10:17:39 -0800
- 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 UTC