> On Mar 20, 2015, at 2:34 PM, Travis Leithead <travis.leith...@microsoft.com> > wrote: > >> 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?
I don't recall any public proposal made. >>> 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...? Let me restate what I tried to say: I think the reason attaching a shadow DOM on input and select elements come up as a use case is because people think it's a mechanism by which we can replace the appearance of those from control elements while preserving semantics and keeping them accessible. Some people have also argued that such an approach will let future platforms to ignore the shadow DOM and use a more platform-appropriate appearance instead. However, I'd argue that's a fraud concept because we can't assume the ARIA role of the shadow DOM to be that of the host element since the shadow DOM can contain multiple "controls" that the user needs to interact with; e.g. input[type=date], for example, may show a calendar widget with a control to select year, month, etc... inside its shadow DOM. We can't ignore the shadow DOM entirely either if it's interacting with scripts since the rest of the page can make depend on the side effects of shadow DOM being there; e.g. updating some global state or sanitizing the value. It's particularly problematic in the case the author intended the shadow DOM to extend the builtin elements because that's precisely when the author assumes the script that attached the shadow DOM to be doing extra work or even providing extra methods and properties on the element via custom elements. - R. Niwa
