- From: Dominic Cooney <dominicc@google.com>
- Date: Thu, 25 Aug 2011 06:30:59 +0900
- 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