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 <espr...@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 <aboxh...@google.com> wrote: > >> >> >> 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. >> > >