> 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
