Bug ID: 28211
Summary: [Shadow]: A syntax for loading/parsing shadow trees
directly from HTML
Component: Component Model
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, email@example.com,
The way I see it, an HTML Import is already a shadow DOM builder (from a URL).
Imports point to a URL, fetch it, parse it (in the context of the parent's
scripting global environment), and then drop the completed document (and it's
dependents) in the 'import' property of the Link element. HTML Imports don't
render the imported document anywhere ('cause it ain't bound to an element
yet--where would you render it?).
If ShadowRoot constructors had the ability to load from a URL, I would propose
that the good parts of HTML Imports be used as the model for the loaded shadow
dom. There would be a few tweaks of course, but the model appears sound to me.
Why is this alluring to me?
* Loading a custom element is more... componentized. The element's shadow dom
(and behavior) can be imported locally in relation to the element host. From
what I have heard recently, custom elements (of sufficient complexity) without
shadow dom doesn't make much sense.
* The URL can be the basis for script-level access control to the component's
shadow dom (a known and well-established pattern that exists for iframe).
* We can reuse much of the existing investment in imports
* Shadow dom components are allowed to independently load resources (e.g.,
notably stylesheets) behind a potentially access-controlled boundary
* Existing patterns for synchronously loading a shadow dom as work today
(without a URL) may be largely unaffected.
You are receiving this mail because:
You are on the CC list for the bug.