Re: Custom Elements: is=""

Removing this breaks several use cases of which there's no alternative
currently:

https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-action.html
https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-button.html

where you want to hook into the focus, tab navigation, and action behavior
in the browser. For example links unfocus in some browsers after unclicking
them. We also don't have a facility to be focusable but not have a tab
index currently.


On Wed, May 6, 2015 at 9:59 AM, Alice Boxhall <aboxhall@google.com> wrote:

>
>
> 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.
>