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.

Welcome to the show!

>
> 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?

I certainly didn't mean to convey either: the former as some new thing
introduced by the Component Model, and the latter as something that is
being attempted.

All it says is that your components are DOM objects and inherit the
DOM Core APIs. You can add your own properties and extend the API
surface.

>
> 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.

Just to reiterate, the Component Model doesn't add or change anything
here that's not possible today.

How can I make this more clear in the overview?

>
>
> 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.

Oh you're right. I need to ratchet down the language. "Information" is
a very heavy word.

>
>
> ---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.

Ah, good point. I need to expand on this. I'll start a thread to discuss.

>
>
> 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 I mentioned in the section, any element that uses more than one CSS
box and isn't specified in terms of CSS. The spec would need to have
an explicit list.

>
> 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>.

For what it's worth, this particular use case has grown into a list
attribute on the input element:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-list.
But more on the multiple shadow DOMs per element thread that's coming
up.

>
>
> 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

I can't seem to draw a parallel between prefixing author-defined
custom DOM elements and prefixing HTTP parameters -- other than the
prefix itself, that is. There's a clear meaning of the prefix in the
Component Model -- this element was defined by an author.
Additionally, we are explicitly trying to avoid a registry-like
situation, where one has to announce or qualify for the right to use a
tag name. Can you help me understand what your concerns are?

>
>
> 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.

Yes! That's why we need folks like you helping out :)

>
>> 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.

Yes, shadow DOM gives the author an extra lever to control visibility
and hackability of their code. It's up to them to use this lever
wisely. This is not without precedent. Just like authors who choose to
use canvas to build their entire applications are shutting the door
(intentionally or not) on extensions, I bet we'll also see these
extremes with the Component Model. However, I am also sure that a lot
of authors will see value in retaining composability for extensions.
If anything, shadow DOM can help authors draw proper composability
boundaries and thus inform extensions developers where tweaking is ok
and where may cause explosions.

:DG<

> Adam
>

Received on Wednesday, 24 August 2011 17:04:25 UTC