Re: Component Model Update

On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth <w3c@adambarth.com> wrote:
> I feel somewhat like I'm walking into the middle of a movie, but I
> have a couple questions.  Please forgive me if my questions have
> already been answer in previous discussions.
>
> On Tue, Aug 23, 2011 at 1:40 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>> All,
>>
>> Over the last few weeks, a few folks and myself have been working on
>> fleshing out the vision for the Component Model. Here's what we've
>> done so far:
>>
>> * Created a general overview document for behavior attachment problem
>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>> * Wrote down the a set of guidelines on how we intend to tackle the
>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>> * Updated the list of use cases and desired properties for each case
>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>> * Captured the overall component model design and how it satisfies
>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>
> This section <http://wiki.whatwg.org/wiki/Component_Model#Consistency>
> seems to imply that components can override the traversal and
> manipulation APIs defined by DOM Core.  Do you mean that they can
> override the JavaScript APIs folks use for traversal and manipulation,
> or can they override the traversal and manipulation APIs used by other
> languages bound to the DOM and internally by specifications?
>
> For example, suppose we implemented the Component Model in WebKit and
> a component overrided the nextSibling traversal API.  Would
> Objective-C code interacting with the component (e.g., via Mac OS X's
> Object-C API for interacting with the DOM) see the original API or the
> override?  Similarly, for browsers such as Safari, Chrome, Firefox,
> and Opera that provide a script-based extension mechanism, would
> extensions interacting with these components (e.g., via isolated
> worlds or XPCNativeWrappers) see the original API or the override?
>
> My sense is that you only mean that Components can shadow (and here I
> mean shadow in the traditional Computer Science sense
> <http://en.wikipedia.org/wiki/Variable_shadowing>) the normal
> traversal and manipulation, not that they can override it, per se.
>
>
> This section <http://wiki.whatwg.org/wiki/Component_Model#Encapsulation>
> says "... and ensures that no information about the shadow DOM tree
> crosses this boundary."  Surely that's an overstatement.  At a
> minimum, I assume the shadow DOM participates in layout, so its height
> and width is leaked.
>
>
> ---8<---
> var shadow2 = new ShadowRoot(this); // throws an exception.
> --->8---
>
> I'm not sure I understand why that's the best design decision.  Maybe
> this is explained elsewhere?  I link would help folks like me
> understand better.  It looks like this design decision is tied up into
> how http://wiki.whatwg.org/wiki/Component_Model#Composability works.
>
>
> This section <http://wiki.whatwg.org/wiki/Component_Model#Desugaring>
> says "... this also explains why you can't add shadow DOM subtrees to
> input or details elements."  It seems unfortunate that some elements
> will accept new ShadowRoots but others will not.  Is this an
> implementation detail?  What's the list of elements that reject
> ShadowRoots?
>
> As an example, it seems entirely reasonable that you'd want to create
> an autocomplete dropdown component for use with an input element.  It
> seems like the natural thing to do would be to subclass the "input"
> element and add an autocomplete dropdown as a shadow DOM.  This design
> choice appears to preclude this use case.  Instead, I need to subclass
> "div" or whatever and replicate the HTMLInputElement API, which seems
> like the opposite of the "reuse existing mechanisms" design principle
> <http://wiki.whatwg.org/wiki/Component_Model_Methodology#Design_Priniciples>.
>
>
> This section <http://wiki.whatwg.org/wiki/Component_Model#Performance>
> says "When an unknown DOM element with an "x-"-prefixed tagName is
> encountered ...".  It seems unfortunate to special-case tag names that
> begin with "x-".  The IETF has a lot of experience with "x-" prefixes,
> and they're somewhat unhappy with them:
>
> http://tools.ietf.org/html/draft-saintandre-xdash
>
>
> This section <http://wiki.whatwg.org/wiki/Component_Model#Confinement_Primitives>
> seems somewhat half-baked at the moment.  It says as much, so I
> presume it's more of a work-in-progress.  Getting confinement right is
> pretty tricky.
>
>> including a handy comparison with existing relevant specs and
>> implementations
>> (http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
>>
>> After of this iteration, the proposed shadow DOM API no longer
>> includes the .shadow accessor (see details here
>> http://dglazkov.github.com/component-model/dom.html). Instead, the
>> shadow DOM subtree association happens in ShadowRoot constructor:
>>
>> var element = document.createElement("div");
>> var shadow = new ShadowRoot(element); // {element} now has shadow DOM
>> subtree, and {shadow} is its root.
>> shadow.appendChild(document.createElement("p")).textContent = "weee!!';
>
> This looks like a substantial improvement.
>
>> Keeping the accessor out allows for proper encapsulation and
>> confinement (better explanation of these new bits of terminology here:
>> https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
>> also simplifies the API surface.
>
> It definitely improves encapsulation in an "honest-but-curious" model.
>  I'm not entirely convinced the confinement story is fully fleshed
> out.
>
>> Please review. Feedback is welcome!
>
> Have you considered how this system interacts with browser extension
> systems?  For example, imagine that a web page sticks its entire DOM
> into a shadow and throws away the pointer.  How is a GreaseMonkey
> script (or an extension's content script if you're familiar with the
> Safari and Chrome extension systems) supposed to apply their magic to
> the page?  In some sense, these scripts provide value by violating
> encapsulation.  Of course, browser vendors could add goofy appendages
> to let these scripts violate encapsulation, but that would still be
> something of a drag on the open re-mix culture we expect of the web.

Just to make this point more concretely, consider this very simple
extension I wrote a little while ago:

https://chrome.google.com/webstore/detail/dkjkhnleklkkccenbnlohlbkbdpdobdb

It's basically a GreaseMonkey script that attaches a behavior to
password fields that alerts you if you're about to enter your password
into an insecure page.  Right now it works great, especially on
Reddit, but if Reddit moves their password input element inside a
shadow DOM, the extension will fail to detect the password field
(because it is encapsulated), and, therefore, will fail to alert me to
the security risk.  That seems like a loss.

Adam

Received on Wednesday, 24 August 2011 04:37:52 UTC