Re: [Shadow] URL-based shadows?

> On Mar 18, 2015, at 4:08 PM, Travis Leithead <travis.leithead@microsoft.com> wrote:
> 
>> From: Ryosuke Niwa [mailto:rniwa@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

Received on Thursday, 19 March 2015 00:34:52 UTC