>Ryosuke Niwa [mailto:rn...@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...?
