Re: xdash name prefixes (was Re: Component Model Update)
On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth w...@adambarth.com wrote: Doesn't it seem more likely that the third-party will do the registration in whatever script you include that implements the Like button, or whatever? That's just a matter of convention, no? I don't think it's unreasonable to frame it as in order to use a component you need to load its source and register a suitable element name for it.. OTOH, there's nothing to prevent a package from doing the registering in one go. But if such a package then really leads to a clash, I'd prefer to first ask the authors to sort it out. Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
I think for convenience registration probably should be carried around with the component, because: 1. It is convenient for the author using the component. 2. If the component library reuses its own abstractions, it probably expects them to have a specific element name. Putting registration in the hands of the author using the component jeopardizes that. However I don’t think the imperative API is right, or at least not enough, for these reasons: (assuming you accept that registration happens in the component library—the death before inconvenience premise): 1. The imperative registration API is *not* OK for confined components, because if you run script out of the library in your context to do the registration, you are hosed. 2. There’s no way for the author to manage conflicts or namespace pollution. Something declarative like module imports and exports, with scoped renaming, for registered tag names would be nice. This avoids these two problems, and is pretty convenient (particularly if import * gets you all of the exports by default.) Dominic On Wed, Aug 31, 2011 at 10:54 AM, Roland Steiner rolandstei...@google.com wrote: On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth w...@adambarth.com wrote: Doesn't it seem more likely that the third-party will do the registration in whatever script you include that implements the Like button, or whatever? That's just a matter of convention, no? I don't think it's unreasonable to frame it as in order to use a component you need to load its source and register a suitable element name for it.. OTOH, there's nothing to prevent a package from doing the registering in one go. But if such a package then really leads to a clash, I'd prefer to first ask the authors to sort it out. Cheers, - Roland
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 31, 2011 at 12:57 PM, Dominic Cooney domin...@chromium.orgwrote: I think for convenience registration probably should be carried around with the component, because: 1. It is convenient for the author using the component. 2. If the component library reuses its own abstractions, it probably expects them to have a specific element name. Putting registration in the hands of the author using the component jeopardizes that. That is actually a good point. Something declarative like module imports and exports, with scoped renaming, for registered tag names would be nice. This avoids these two problems, and is pretty convenient (particularly if import * gets you all of the exports by default.) Wouldn't that be effectively namespaces by another name/mechanism? Also, there's probably a limit to how far renaming can avoid clashes, e.g., if a sub-components can also be utilized by a page's author. In any case, until modules become a reality I think teaching component authors to use pseudo-namespaces (e.g., x-rogersoft-button vs. x-delilahsoft-button) for stuff that might clash is not unreasonable. Cheers, - Roland
Re: Component Model Update
On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney domin...@google.com wrote: Here is a quick first cut: How about use cases like these: - Extension that wants to inspect input type=password and warn you when you are entering you password in an insecure form (from abarth earlier in the thread.) - Password manager that wants to find anything that looks like a login panel and decorate it/fill it. - Extension that removes formatting from a page to make it easier for on-screen reading. - Extension that finds phone numbers in a page and embosses them with links to a crank call service. - Extension that replaces all ads in a page with pictures of kittens. Or an extension that detects pictures of kittens and monetizes them with ads. - Extension that on hover looks up dictionary/thesaurus/translation/urban dictionary/wikipedia/etc. This is a great list! As for allowing extensions to inspect the shadow DOM: unless we want to break isolation/confinement again, I believe this should be handled by the relevant browser APIs for extensions, along the lines of shadow = extensions.getShadowFor(element). If the extension shouldn't be able to mess with shadows, it can be blocked at this point.
Re: xdash name prefixes (was Re: Component Model Update)
On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth w...@adambarth.com wrote: On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button Since the components that are used on a page are under the control of the page's author, it should be possible to avoid clashes by separating a component's definition (potentially pulled from third party) from its tag registration (done by page author), e.g. // Importing component definition for Facebook Like button // Importing component definition for Google+ +1 button // ... later: Element.register(x-fb, Facebook.LikeButton) Element.register(x-gg, GooglePlus.PlusOneButton) That's something like 40% of the use cases... I don't have much of a better suggestion. You're running up against all the usual distributed extensibility issues. We could use namespaces... *ducks and runs* :D Cheers, - Roland
Re: Component Model Update
On Fri, Aug 26, 2011 at 12:42 AM, Roland Steiner rolandstei...@google.com wrote: On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney domin...@google.com wrote: Here is a quick first cut: How about use cases like these: - Extension that wants to inspect input type=password and warn you when you are entering you password in an insecure form (from abarth earlier in the thread.) - Password manager that wants to find anything that looks like a login panel and decorate it/fill it. - Extension that removes formatting from a page to make it easier for on-screen reading. - Extension that finds phone numbers in a page and embosses them with links to a crank call service. - Extension that replaces all ads in a page with pictures of kittens. Or an extension that detects pictures of kittens and monetizes them with ads. - Extension that on hover looks up dictionary/thesaurus/translation/urban dictionary/wikipedia/etc. This is a great list! As for allowing extensions to inspect the shadow DOM: unless we want to break isolation/confinement again, I believe this should be handled by the relevant browser APIs for extensions, along the lines of shadow = extensions.getShadowFor(element). If the extension shouldn't be able to mess with shadows, it can be blocked at this point. Yes, I think a separate function for doing the lookup is a good idea. It keeps the set of attributes and methods on a given DOM object the same for pages and extensions. Dominic
Re: xdash name prefixes (was Re: Component Model Update)
On Fri, Aug 26, 2011 at 1:07 AM, Roland Steiner rolandstei...@google.com wrote: On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth w...@adambarth.com wrote: On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button Since the components that are used on a page are under the control of the page's author, it should be possible to avoid clashes by separating a component's definition (potentially pulled from third party) from its tag registration (done by page author), e.g. // Importing component definition for Facebook Like button // Importing component definition for Google+ +1 button // ... later: Element.register(x-fb, Facebook.LikeButton) Element.register(x-gg, GooglePlus.PlusOneButton) Doesn't it seem more likely that the third-party will do the registration in whatever script you include that implements the Like button, or whatever? Adam That's something like 40% of the use cases... I don't have much of a better suggestion. You're running up against all the usual distributed extensibility issues. We could use namespaces... *ducks and runs* :D Cheers, - Roland
Re: Component Model Update
On Thu, Aug 25, 2011 at 2:03 PM, John J Barton johnjbar...@johnjbarton.com wrote: I'm still trying to digest this, but it seem pretty clear the 'confinement' is the clear scope thing I was asking about on es-discuss. According to that discussion, this means needs to fit with the 'modules' thing on ecmascript. That seems to be where you are headed, but basing a new proposal on another new proposal is ... well I'll let you fill in the blank depending on how you are feeling. Courageous? I guess the actual implementation of confined script evaluation would not be difficult (Firefox can do it now if you can get some one to explain it). Getting the entire 'modules' effort out? I'm thinking that could be hard. jjb If we do the design so that good things are possible when modules arrive, and the component model is useful for some use cases even without hermetic confinement, then it sounds reasonable to work on specing, implementing and getting experience with the other parts?
Re: Component Model Update
Here is a quick first cut: How about use cases like these: - Extension that wants to inspect input type=password and warn you when you are entering you password in an insecure form (from abarth earlier in the thread.) - Password manager that wants to find anything that looks like a login panel and decorate it/fill it. - Extension that removes formatting from a page to make it easier for on-screen reading. - Extension that finds phone numbers in a page and embosses them with links to a crank call service. - Extension that replaces all ads in a page with pictures of kittens. Or an extension that detects pictures of kittens and monetizes them with ads. - Extension that on hover looks up dictionary/thesaurus/translation/urban dictionary/wikipedia/etc. How does it change desired properties? The desired properties are good for the page. Extensions can typically exercise capabilities the page has (right?) Extensions can additionally violate encapsulation. However the UA may bless some encapsulation as inviolate (when the implementation uses shadow and wants to rely on nobody—not even extensions—messing with it.) Extensions sometimes have their own notion of confinement. I think it is OK if extensions can’t violate confinement. There is no deep reflective API for JavaScript, so it would not be so useful anyway? How does it change the primitives? Extensions can detect which elements have shadow, get the shadow root, and get the host for a given shadow root. (In addition to creating shadow roots and any other typical DOM manipulations an extension can do.) Do any of the above use cases need to access the flattened tree? If so, maybe there should be an API for that, because computing it in script would be tedious. Dominic On Thu, Aug 25, 2011 at 1:06 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 8:23 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. Let me see if I can capture this into a feature: user scripts may have access to shadow DOM subtrees. In terms of WebKit, when run in user script worlds, the Element has an extra accessor to spelunk down the shadow DOM. Is this what you're suggesting? Yes. Encapsulation is good UI, not security. I want to ignore the subtree normally but jump into the astral plane for special enlightenment. XUL has such a mechanism, but I'd wish for less mystery. I spent many hours trying to keep element inspection working on XUL. The API should aim to work well with code designed for normal elements. jjb Ok. Can you help me formulating a use case for this API, and how it affects desired properties, and building blocks? Anybody has an allergic reaction to something like this? :DG :DG jjb
Re: Component Model Update
On 08/23/2011 11:40 PM, Dimitri Glazkov 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),
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!!';
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
It would be rather strange if one needs to explicitly construct
shadow tree after the element is created.
(Component Model is getting closer and closer to XBL, and it is not
quite clear to me why XBL2 couldn't be used. It needs some
minor fixes, but should work otherwise.)
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.
Please review. Feedback is welcome!
:DG
Re: Component Model Update
On Thu, Aug 25, 2011 at 5:41 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/23/2011 11:40 PM, Dimitri Glazkov 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),
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!!';
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
It would be rather strange if one needs to explicitly construct
shadow tree after the element is created.
Looking at the use cases, it looks like components need to run script
anyway, at least to hook up event listeners. So would it be fair to
rephrase this as: “There should be a concise way to get HTML into a
shadow tree.” ?
(Component Model is getting closer and closer to XBL, and it is not
quite clear to me why XBL2 couldn't be used. It needs some
minor fixes, but should work otherwise.)
I feel like XBL2 doesn’t get the power-to-weight ratio right—it looks
hard to use and implement, and as this
http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations
summarizes XBL2 doesn’t mesh well with JavaScript, and doesn’t get
confinement. So this proposal looks like it made a good tradeoff…
eliminate a lot of what’s complex to use and implement in XBL2, and
focusses instead on useful capabilities like confinement.
Dimitri et al studied XBL2 in depth in designing the component model.
It is possible when you follow through with minor fixes to XBL2 you
will end up here anyway… it might be more productive to work on
fleshing out and fixing this proposal.
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.
Please review. Feedback is welcome!
:DG
Re: Component Model Update
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fiwrote: One thing missing is some kind of declarative way to define shadow trees, similar to XBL1's content. I think this omission is a big plus. XBL1 content is mysterious. If a dev tool wants to add support for building Components from declarative markup, awesome. But the bizarre combo of xml, .css, and .js in XBL one is poorly supported by tooling and thus is just a mess. Create a great JS solution then let tools build on that. jjb
Re: Component Model Update
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote: One thing missing is some kind of declarative way to define shadow trees, similar to XBL1's content. It would be rather strange if one needs to explicitly construct shadow tree after the element is created. I know we plan to add a declarative syntax similar to XBL, but the scripted syntax gets into the details better, so it's better to focus on that first. It's also easy, when you start from a declarative solution, to accidentally build in magic that's hard to replicate imperatively. Starting from imperative has similar risks, but I think they're easier to manage. ~TJ
[Component Model] Declarative syntax for shadow DOM subtrees, was Re: Component Model Update
On Thu, Aug 25, 2011 at 8:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote: One thing missing is some kind of declarative way to define shadow trees, similar to XBL1's content. It would be rather strange if one needs to explicitly construct shadow tree after the element is created. I know we plan to add a declarative syntax similar to XBL, but the scripted syntax gets into the details better, so it's better to focus on that first. It's also easy, when you start from a declarative solution, to accidentally build in magic that's hard to replicate imperatively. Starting from imperative has similar risks, but I think they're easier to manage. Splitting into a fresh thread. I also think being able to use markup to declare shadow DOM trees is pretty cool, however I would strongly recommend coming up with a use case that clearly illustrates the need for it. Now that we have a fairly rigorous framework around this spec development (http://wiki.whatwg.org/wiki/Component_Model_Methodology), we should follow it. So we have to answer this question first: Why and to Whom is it important to have such a feature? One notion I was toying with is productivity, since declarative markup should be easier to read. Another possible point is consistency: we can build DOM trees using markup in a document, why not in shadow DOM? I don't think performance quite cuts it anymore, since JS engines have gotten to the point where I doubt you'll see a significant difference between declarative and imperative tree instantiation. :DG
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 5:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth w...@adambarth.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@adambarth.com wrote: 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. Yeah, the parallel breaks down a bit because in HTTP the X- names are used by two parties and here we're only talking about one party. Maybe a better parallel is data attributes, which are also segmented into their own namespace... Yes, the data-* attributes are the correct thing to draw parallels to here. On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button That's something like 40% of the use cases... These are fine as well; the important case where prefixing causes problems is when one of the parties is the browser itself, where it will eventually want to change from recognizing the prefixed name to recognizing the unprefixed name. That's a pretty narrow view. :) Adam
Re: Component Model Update
On 08/23/2011 11:40 PM, Dimitri Glazkov 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),
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 is getting a bit better, more XBL2-like, but just with different
syntax :)
Adam already sent comments about most of the things I had in mind
and I'm especially interested to know about
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. since that could have major
effects to browser engine architecture. If all the APIs could be
overridden, and browser engine is expected to call the JS implemented
versions, the problems we have now with mutation events would be there
with all the DOM methods.
The wiki page doesn't mention at all how events are propagated.
I assume mousemove events should be fired in the real dom, but also in
shadow dom? mouseover/out should in some cases fire only in shadow dom,
but in some cases both in shadow and real...etc.
Is the idea to clone events like in XBL2, or propagate but
re-target like in XBL1 or what?
-Olli
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.
Please review. Feedback is welcome!
:DG
Re: Component Model Update
Hi Olli!
On Wed, Aug 24, 2011 at 3:13 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/23/2011 11:40 PM, Dimitri Glazkov 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),
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 is getting a bit better, more XBL2-like, but just with different syntax
:)
I am glad you like it!
Adam already sent comments about most of the things I had in mind
and I'm especially interested to know about
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. since that could have major effects
to browser engine architecture. If all the APIs could be
overridden, and browser engine is expected to call the JS implemented
versions, the problems we have now with mutation events would be there
with all the DOM methods.
The wiki page doesn't mention at all how events are propagated.
I assume mousemove events should be fired in the real dom, but also in
shadow dom? mouseover/out should in some cases fire only in shadow dom,
but in some cases both in shadow and real...etc.
Is the idea to clone events like in XBL2, or propagate but
re-target like in XBL1 or what?
The event propagation is already mostly spec'd out here:
http://dglazkov.github.com/component-model/events.html
Propagation through content element and handling evenets for the
confinement primitives isn't yet done.
:DG
-Olli
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.
Please review. Feedback is welcome!
:DG
Re: Component Model Update
On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@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 dglaz...@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
Re: Component Model Update
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: 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. Maybe I grew up on to much Web koolaid, but browsers should be giving all extra levers to users. In real life control in the hand of authors means control in the hands of suits and suits will always pick the hide all setting. 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. In the case of canvas the reason is technical inferiority, the medium is write only. Component Model has not such technical limit. 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. Again, that's old school. Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. jjb
xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@adambarth.com wrote: 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. Yeah, the parallel breaks down a bit because in HTTP the X- names are used by two parties and here we're only talking about one party. Maybe a better parallel is data attributes, which are also segmented into their own namespace... On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button That's something like 40% of the use cases... I don't have much of a better suggestion. You're running up against all the usual distributed extensibility issues. Adam
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth w...@adambarth.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@adambarth.com wrote: 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. Yeah, the parallel breaks down a bit because in HTTP the X- names are used by two parties and here we're only talking about one party. Maybe a better parallel is data attributes, which are also segmented into their own namespace... Yes, the data-* attributes are the correct thing to draw parallels to here. On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button That's something like 40% of the use cases... These are fine as well; the important case where prefixing causes problems is when one of the parties is the browser itself, where it will eventually want to change from recognizing the prefixed name to recognizing the unprefixed name. ~TJ
Re: Component Model Update
On Wed, Aug 24, 2011 at 2:50 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: 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. Maybe I grew up on to much Web koolaid, but browsers should be giving all extra levers to users. In real life control in the hand of authors means control in the hands of suits and suits will always pick the hide all setting. 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. In the case of canvas the reason is technical inferiority, the medium is write only. Component Model has not such technical limit. 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. Again, that's old school. Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. Let me see if I can capture this into a feature: user scripts may have access to shadow DOM subtrees. In terms of WebKit, when run in user script worlds, the Element has an extra accessor to spelunk down the shadow DOM. Is this what you're suggesting? :DG jjb
Re: Component Model Update
On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. Let me see if I can capture this into a feature: user scripts may have access to shadow DOM subtrees. In terms of WebKit, when run in user script worlds, the Element has an extra accessor to spelunk down the shadow DOM. Is this what you're suggesting? Yes. Encapsulation is good UI, not security. I want to ignore the subtree normally but jump into the astral plane for special enlightenment. XUL has such a mechanism, but I'd wish for less mystery. I spent many hours trying to keep element inspection working on XUL. The API should aim to work well with code designed for normal elements. jjb :DG jjb
Re: Component Model Update
On Wed, Aug 24, 2011 at 8:23 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. Let me see if I can capture this into a feature: user scripts may have access to shadow DOM subtrees. In terms of WebKit, when run in user script worlds, the Element has an extra accessor to spelunk down the shadow DOM. Is this what you're suggesting? Yes. Encapsulation is good UI, not security. I want to ignore the subtree normally but jump into the astral plane for special enlightenment. XUL has such a mechanism, but I'd wish for less mystery. I spent many hours trying to keep element inspection working on XUL. The API should aim to work well with code designed for normal elements. jjb Ok. Can you help me formulating a use case for this API, and how it affects desired properties, and building blocks? Anybody has an allergic reaction to something like this? :DG :DG jjb
Re: Component Model Update
I'm still trying to digest this, but it seem pretty clear the 'confinement' is the clear scope thing I was asking about on es-discuss. According to that discussion, this means needs to fit with the 'modules' thing on ecmascript. That seems to be where you are headed, but basing a new proposal on another new proposal is ... well I'll let you fill in the blank depending on how you are feeling. I guess the actual implementation of confined script evaluation would not be difficult (Firefox can do it now if you can get some one to explain it). Getting the entire 'modules' effort out? I'm thinking that could be hard. jjb
Component Model Update
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),
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!!';
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.
Please review. Feedback is welcome!
:DG
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 dglaz...@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
Re: Component Model Update
On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@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 dglaz...@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
