Re: Custom Elements: is=""

On Wed, May 6, 2015 at 8:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, May 6, 2015 at 4:46 PM, Léonie Watson <lwatson@paciellogroup.com>
> wrote:
> > My understanding is that sub-classing would give us the accessibility
> inheritance we were hoping is= would provide. Apologies if I've missed it
> somewhere obvious, but is there any information/detail about the proposed
> sub-classing feature available anywhere?
>
> It should fall out of figuring out HTML as Custom Elements. Apart from
> styling which I think we can solve independently to some extent that's
> the big elephant in the room.
>

As I see it there are two problems which is= could conceivably solve, which
seem to be being conflated:
- providing access to capabilities which so far only native elements have
(roles not captured by ARIA, forms behaviour, etc)
- allowing re-use of the bundled complete set of behaviours captured in
each element in the platform (what is focusable, what keyboard interactions
work, what happens on mobile vs. desktop, what semantic values are exposed
- essentially everything required in the HTML specs for that particular
element)

A solution to the first problem I agree should fall out of the HTML as
custom elements effort.

The second is the one I'm more concerned about falling off the radar: when
using a native <button>, you can be reasonably certain that it will adhere
to the HTML spec in behaviour; when using an <x-button>, you only have the
reputation of the custom element vendor to give you any sort of guarantee
about behaviour, and it could regress at any time.

I definitely acknowledge is= may not be the ideal solution to the latter
problem - it definitely has some holes in it, especially when you start
adding author shadow roots to things - but I think it does have potential.
I'd really like to be convinced that we either have a reasonable
alternative solution, or that it's not worth worrying about.