W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Component Model Update

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Wed, 24 Aug 2011 21:06:29 -0700
Message-ID: <CADh5Ky1pAzqdQk5paRqO8P0YnxbNM17nMzEj-o1=H4i19C1RJg@mail.gmail.com>
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 GMT

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