> On Mar 18, 2015, at 4:08 PM, Travis Leithead <travis.leith...@microsoft.com> 
> wrote:
>> 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).

We’re still very much interested in pursuing this use case.

> 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.

The reason I made that proposal was because we didn’t want to have two 
completely separate APIs for defining same-origin and cross-origin components.  
In the ideal world, we would have single component model that works across 
same-origin as well as cross-origin with varying degrees of freedom and 
restrictions.  I agree that same-origin components that run in the context of 
the hosting document/page is a lot more interesting from spec and 
implementation complexity because it involves more complicated features of 
shadow DOM such as insertion points but that doesn’t preclude us from making 
sure cross-origin scenario works just as well.

> 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.

This approach works for same-origin use cases but we couldn’t come up with a 
good imperative API for cross-origin scenarios.

> 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.

That use case comes up frequently on this list but I think that needs to be 
addressed by CSS-based decorators.  If we let custom “appearance” add a JS API, 
then UA wouldn’t be able to rip it apart for accessibility or for new platforms.

- R. Niwa

Reply via email to