> From: Ryosuke Niwa [mailto:rn...@apple.com]
>I think this idea resonates well with the cross-origin use case / API change 
>proposal we made two years ago [1].  In that proposal, we went a step further 
>and tied custom elements with URLs so that those shadow DOM can be 
>automatically instantiated by simply using those custom elements.

Thanks for the referral Ryosuke!

In reading the proposal [1], I understood the following points (that interested 
me anyway):
1. Separate (isolated) script engine (your point #1 wanting to modify imports). 
Facilitates iframe-like isolation between host and root to enable cross-origin 
use case.
2. Importing document manually declares the desired custom elements. Very 
elegant.
3. Shadow DOMs limited to custom elements.
4. Many declarative extensions to template to enable custom element bindings. I 
see you recognized template's powers at creating a non-rendered shadow-dom 
already, and just took the leap to figure out how to auto bind them to custom 
elements :-)
5. Expose dataset to the root (even cross-domain)

I'm not sure if you are still interested in pursuing all of these features, or 
what their importance/weight is at this point (two years later).

Some of my opinions, matching the numbering up to the above list:
1. I think one of the things that makes web components separate and interesting 
from existing iframes is the fact that they load and run "in context", in other 
words, in the context of the global script engine of the hosting page. I don't 
think there's anything inherently wrong with how "components" loaded via 
iframes work today, so the cross-origin use case for web components is not 
something I'm motivated to solve (using web components). I suspect that a 
cross-origin use case is important, but its level of integration will of 
necessity be more limited, and I suspect it will lead to a different design 
than what we have with current web components.
2.&4. I keep running into trouble when thinking about a declarative model for 
web components because declarative models are based on persistent objects in 
the DOM, and those persistent objects are fully mutable. In other words, you 
have to either accept and spec accordingly what happens when key attributes are 
changed (e.g., your "defines" and "interface" attributes), or you have to limit 
mutability such that changes are only read-once (for example). I prefer to let 
frameworks write the declarative syntactic sugar in the case of web components, 
and steer clear of declarative models unless the mutability works in favor of 
the proposal.
3. I don't have an opinion here yet. It seems like limiting to custom elements 
makes shadow dom easier to implement. But I can also imagine cases where the 
component really wants to hook up to an element like <input> or <select> in 
order to extend its host's feature set.
5. I like this. Though it's really only necessary for the cross-origin use case.

[1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html


From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Wednesday, March 18, 2015 2:26 PM
To: Travis Leithead
Cc: Dimitri Glazkov (dglaz...@google.com); WebApps WG; Anne van Kesteren 
(ann...@annevk.nl); Arron Eicholz
Subject: Re: [Shadow] URL-based shadows?


On Mar 12, 2015, at 5:46 PM, Travis Leithead <travis.leith...@microsoft.com> 
wrote:
 
   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.

Hi Travis,

I think this idea resonates well with the cross-origin use case / API change 
proposal we made two years ago [1].  In that proposal, we went a step further 
and tied custom elements with URLs so that those shadow DOM can be 
automatically instantiated by simply using those custom elements.

e.g. if “like-button” element was defined in 
https://webkit.org/components.html, then we can use that component by simply 
"importing" the definition:

<link rel=import href="https://webkit.org/components.html"; 
defines="like-button”>

and using it in the same document (that imported components.html):

<like-button data-url="https://build.webkit.org/";>Like 
build.webkit.org</like-button>

We thought this model was more developer friendly than having each user of the 
component manually create shadow root.  We also didn’t want to make component 
authors deal with situations like a shadow root being attached to an iframe, 
input, etc..

[1] https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html

- R. Niwa

Reply via email to