Ah, thanks Dimitri.

After reading that, I'm also receiving it rather "coolly". It's a very 
interesting idea, but as it relates to web components, its errs strongly on the 
side of isolation to the degree that the component would be more isolated than 
an iframe today; at least in same-domain, non-sandboxed iframes, you can 
directly access the document via the contentWindow property if desired; 
furthermore styling of this DOMWorker thing which is running in a separate 
thread would be complex to say the least from an implementation standpoint. I 
definitely want to stay firmly on the same thread for Shadow DOMs ??.

Back to what I'm thinking...

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.

From: Dimitri Glazkov <dglaz...@google.com>
Sent: Friday, March 13, 2015 10:44 AM
To: Travis Leithead
Cc: WebApps WG; Anne van Kesteren (ann...@annevk.nl); Arron Eicholz; Elliott 
Subject: Re: [Shadow] URL-based shadows?

... found it: 


On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov 
<dglaz...@google.com<mailto:dglaz...@google.com>> wrote:
Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly 
received (can't remember the details).


On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead 
<travis.leith...@microsoft.com<mailto:travis.leith...@microsoft.com>> wrote:
Dimitri et al.,

   Has the idea of loading/parsing a Shadow DOM directly from a URL been 
discussed already? (e.g., a sort-of "micro-import" or an import that parses its 
document directly into the ShadowRoot container?) I'm curious to know if 
there's some obvious flaw that I'm missing.

element.createShadowRoot("path to my component");

  This is an idea around building components from the "inside out", and using 
the URL as the basis for script-level access control to the Shadow contents.


Reply via email to