- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 24 Aug 2011 21:06:29 -0700
- To: John J Barton <johnjbarton@johnjbarton.com>
- Cc: Dominic Cooney <dominicc@google.com>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
On Wed, Aug 24, 2011 at 8:23 PM, John J Barton <johnjbarton@johnjbarton.com> wrote: > > > On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov <dglazkov@chromium.org> > wrote: > >> >> > Independent of our different point of view on control, shadow DOM needs >> > debug APIs. So much the better if these are available to extensions. >> >> Let me see if I can capture this into a feature: user scripts may have >> access to shadow DOM subtrees. In terms of WebKit, when run in user >> script worlds, the Element has an extra accessor to spelunk down the >> shadow DOM. >> >> Is this what you're suggesting? > > Yes. Encapsulation is good UI, not security. I want to ignore the subtree > "normally" but jump into the astral plane for special enlightenment. > XUL has such a mechanism, but I'd wish for less mystery. I spent many hours > trying to keep element inspection working on XUL. The API should aim to work > well with code designed for normal elements. > jjb Ok. Can you help me formulating a use case for this API, and how it affects desired properties, and building blocks? Anybody has an allergic reaction to something like this? :DG< >> >> :DG< >> >> > >> > jjb >> > > >
Received on Thursday, 25 August 2011 04:06:55 UTC