> 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

Reply via email to