W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Component Model Update

From: Dominic Cooney <dominicc@google.com>
Date: Thu, 25 Aug 2011 06:30:59 +0900
Message-ID: <CAHnmYQ8fmyTZTmfRe0Z69bJQ7JHo572VGFG3fd0YGDCis=V18g@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@chromium.org>
Cc: 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>
On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> 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?

That RFC is interesting, but I didn’t find it a perfect parallel either.

In protocol headers, clients and servers need to agree on the meaning
of headers, and require migration from non-standard to standard
headers with attendant interoperability issues. Components are
different, because both the x-name and its definition are under
control of the author. The intent is that if HTML standardizes an
x-name, it will be christened with the un-prefixed name; the UA can
continue supporting old x-names and definitions using the generic
component mechanism.

I guess we could get into interoperability difficulties if user agents
start to rely on specific x-names and ignoring or augment their
definitions. For example, if a crawler ignores the scripts that define
components but interpret a common x-name a particular way. Or if a
browser automatically augments the definition of a given x-name for
better security or accessibility.

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

Actually, some APIs like Objective-C bindings or extensions have
extraordinary agency. Why shouldn’t they be able to dig into
components? However I think it is OK to expect them to understand
shadows (ie there is a shadows collection on an element, or a function
that maps an element to its shadows.)

> :DG<
>> Adam
Received on Wednesday, 24 August 2011 21:31:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC