W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: [Shadow] URL-based shadows?

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Fri, 13 Mar 2015 19:57:35 +0000
To: Dimitri Glazkov <dglazkov@google.com>
CC: WebApps WG <public-webapps@w3.org>, "Anne van Kesteren (annevk@annevk.nl)" <annevk@annevk.nl>, Arron Eicholz <arronei@microsoft.com>, Elliott Sprehn <esprehn@google.com>
Message-ID: <1426276652985.35973@microsoft.com>
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 <dglazkov@google.com>
Sent: Friday, March 13, 2015 10:44 AM
To: Travis Leithead
Cc: WebApps WG; Anne van Kesteren (annevk@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 <dglazkov@google.com<mailto:dglazkov@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.leithead@microsoft.com<mailto:travis.leithead@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?
Received on Friday, 13 March 2015 19:58:05 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:26 UTC