On Wed, May 6, 2015 at 8:33 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Wed, May 6, 2015 at 4:46 PM, Léonie Watson <lwat...@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.
