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
Sprehn
Subject: Re: [Shadow] URL-based shadows?
... found it:
https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1
:DG<
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).
:DG<
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.
Thoughts?
