Re: Component Model Update

Here is a quick first cut:

How about use cases like these:

- Extension that wants to inspect <input type="password"> and warn you
when you are entering you password in an insecure form (from abarth
earlier in the thread.)
- Password manager that wants to find anything that looks like a login
panel and decorate it/fill it.
- Extension that removes formatting from a page to make it easier for
on-screen reading.
- Extension that finds phone numbers in a page and embosses them with
links to a crank call service.
- Extension that replaces all ads in a page with pictures of kittens.
Or an extension that detects pictures of kittens and monetizes them
with ads.
- Extension that on hover looks up
dictionary/thesaurus/translation/urban dictionary/wikipedia/etc.

How does it change desired properties? The desired properties are good
for the page. Extensions can typically exercise capabilities the page
has (right?) Extensions can additionally violate encapsulation.
However the UA may bless some encapsulation as inviolate (when the
implementation uses shadow and wants to rely on nobody—not even
extensions—messing with it.) Extensions sometimes have their own
notion of confinement. I think it is OK if extensions can’t violate
confinement. There is no deep reflective API for JavaScript, so it
would not be so useful anyway?

How does it change the primitives? Extensions can detect which
elements have shadow, get the shadow root, and get the host for a
given shadow root. (In addition to creating shadow roots and any other
typical DOM manipulations an extension can do.) Do any of the above
use cases need to access the "flattened" tree? If so, maybe there
should be an API for that, because computing it in script would be
tedious.

Dominic

On Thu, Aug 25, 2011 at 1:06 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> 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 07:25:21 UTC