- From: Dominic Cooney <dominicc@google.com>
- Date: Thu, 25 Aug 2011 16:24:49 +0900
- To: Dimitri Glazkov <dglazkov@chromium.org>
- Cc: John J Barton <johnjbarton@johnjbarton.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>
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