Re: Minimum viable custom elements

> On Jan 16, 2015, at 9:43 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> 
> 
> On 16 January 2015 at 16:52, Anne van Kesteren <annevk@annevk.nl <mailto:annevk@annevk.nl>> wrote:
>  Again, I think that unless we solve the styling problem for
> native elements, we're not going to see them adopted, not even if you
> can subclass them (and proper subclassing without the is="" hack is
> another hard problem, as explained).
> 
> The demo i pointed to previously by Alice Boxhall from Google appears to overcome the styling of checkboxes/radio buttons issue
> https://rawgit.com/alice/web-components-demos/master/index.html <https://rawgit.com/alice/web-components-demos/master/index.html>  (view in chrome)

That demo seems to work because the only thing it's doing is changing the appearance of radio buttons and checkboxes.  But this approach poses some implementation challenges for us (WebKit/Safari) because we need to ignore the "rendered" (what's displayed on screen) content and follow the underlying DOM.

Imagine someone had put two radio buttons inside the shadow DOM of a radio button.  Now, we might say that's non-sensical but my point is that authors could do that since there's nothing that prevents them from doing it.  In that case, should we expose a single underlying radio button to AT or should we expose two radio buttons as shown on the screen?

It's possible we can specify some well defined behavior - e.g. we could say that we use underlying DOM element's accessibility role in the absence of any explicit or implicit aria roles in its shadow DOM.  But at that point, we don't even need to use is="" attribute.  Since UAs would know which element inherits from what element, we could use that information to implement such a behavior.

- R. Niwa