This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28211 - [Shadow]: A syntax for loading/parsing shadow trees directly from HTML
Summary: [Shadow]: A syntax for loading/parsing shadow trees directly from HTML
Status: RESOLVED WORKSFORME
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14978
  Show dependency treegraph
 
Reported: 2015-03-13 20:44 UTC by Dimitri Glazkov
Modified: 2015-03-27 20:31 UTC (History)
4 users (show)

See Also:


Attachments

Description Dimitri Glazkov 2015-03-13 20:44:31 UTC
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0800.html

From Travis:

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.
Comment 1 Dimitri Glazkov 2015-03-13 20:59:36 UTC
This is intriguing. What problem are you trying to solve?

On one hand, it neatly solves the problem in bug 22255.

On another hand, it couples imports, templates, and shadow trees too tightly. 

Currently, imports can have as many templates or any other things in them, which enables mechanical concatenation (with some care).
Comment 2 Travis Leithead [MSFT] 2015-03-27 20:31:21 UTC
I've thought some more about this, and worked through the cross-origin use cases a little more, and now I'm agreeing with you much more that this coupling of Shadow DOM and imports is a little too tight.

The Cross-origin usage scenario will definitely involve a URL though. And my most recent thoughts are that the URL doesn't apply so much to ShadowDOM as it does to the custom element binding. Perhaps I'll put together a more complete draft of this thinking and float it by the WG.

Resolving this bug for now. Thanks!