- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Fri, 20 Mar 2015 21:34:43 +0000
- To: Ryosuke Niwa <rniwa@apple.com>
- CC: "Dimitri Glazkov (dglazkov@google.com)" <dglazkov@google.com>, WebApps WG <public-webapps@w3.org>, "Anne van Kesteren (annevk@annevk.nl)" <annevk@annevk.nl>, Arron Eicholz <arronei@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Edward O'Connor <eoconnor@apple.com>
>Ryosuke Niwa [mailto:rniwa@apple.com] wrote: > >> Travis wrote: >> 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. Focusing on the imperative API for cross-origin scenarios sounds like a useful endeavor to continue. Can you refer me to older proposals to review? >> 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. Can you clarify what you mean by that last sentence? I don't follow...?
Received on Friday, 20 March 2015 21:35:12 UTC