Re: Custom Elements: is=""

It might be good to document these on the wiki? Would be lost otherwise.

:DG<

On Wed, May 6, 2015 at 11:53 AM, Elliott Sprehn <esprehn@chromium.org>
wrote:

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