Re: Component Model Update

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.

Adam

Received on Wednesday, 24 August 2011 04:20:42 UTC