Re: [w3c/webcomponents] Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? (#762)

Here's my attempt of summarizing the discussions we've had so far.

In [2018 TPAC](https://github.com/w3c/webcomponents/issues/762#issuecomment-433452748), we concluded that we wanted to respect platform differences. One approach considered is adding the ability to match other element's behavior. One of the [simplest approach propsoed by tkent-google](https://github.com/w3c/webcomponents/issues/762#issuecomment-483909818) is to add a signle boolean like `defaultTabindexFocusFlag` in `ElementIntenals`. [Domenic's counter propsal](https://github.com/w3c/webcomponents/issues/762#issuecomment-484262443) is that we may need tri-state to capture click vs. keyboard focusability. [I pointed out](https://github.com/w3c/webcomponents/issues/762#issuecomment-488873615) that Safari differentiates editable and non-editable form contorls as well as hyper links so we may need four different states along with a point that listing exactly what Safari needs won't be future proof.

In [2019 TPAC](https://www.w3.org/2019/09/17-components-minutes.html#item07), we discussed the idea of using ARIA role as a way of detecting which element is focusable. [Alice proposed](https://github.com/w3c/webcomponents/issues/762#issuecomment-542509589) that if we ignored non-editable form control behavior, we can narrow the cateogires down to four: unfocusable, programatically focusable, user focusable but keyboard focusable depending on UA, and always keyboard focusable. [Maciej then pointed out](https://github.com/w3c/webcomponents/issues/762#issuecomment-542518984) that Safari doesn't include all form controls in the tab order; only editable ones like `textarea` is included. [Tkent then brings up](https://github.com/w3c/webcomponents/issues/762#issuecomment-552334763) that at 2019 TPAC, we came to a conseusus to introduce a high level categories and sgugests: `unfocusable`, `general`, and `control`. There was [some bikeshedding](https://github.com/w3c/webcomponents/issues/762#issuecomment-557488222).

After more bikeshedding, [Alice suggested](https://github.com/w3c/webcomponents/issues/762#issuecomment-596352303) that we can have four categories: unfocusable, programmatically focusable, user focusable but UA dependent for tab order, and user focusable and always in tab order. [Maciej points out](https://github.com/w3c/webcomponents/issues/762#issuecomment-596361286) that if we split "accepts text input" (i.e. editability) into its own property, then we need two states but suggested that tri-state is simpler: `text-input-control`, `control`, `non-control`. [Alice then suggests](https://github.com/w3c/webcomponents/issues/762#issuecomment-596366889) that we can have "sequential" and "auto" instead where the former means always in tab-order and the latter means UA decides. In Maciej also questioned why we need [programatic focusability separately](https://github.com/w3c/webcomponents/issues/762#issuecomment-596361286) and [Alice replies](https://github.com/w3c/webcomponents/issues/762#issuecomment-596372747) that some complex widgets would need this capability to control which sub-components would need focusing. [Maciej mentions](https://github.com/w3c/webcomponents/issues/762#issuecomment-596372912) that leaving UA to decide what is in tab order will result in developers writing components that don't play nicely with platform conventions. Then there are some macOS specific UI discussions.

More recently, [Domenic pointed out](https://github.com/w3c/webcomponents/issues/762#issuecomment-606761250) that this propopsal needs to also make the focusable custom element [interactive content](https://html.spec.whatwg.org/#interactive-content) as it affects `label` element's behavior. Then [Alex pointed out](https://github.com/w3c/webcomponents/issues/762#issuecomment-623192588) that we may also need to [trigger autofocus](https://github.com/w3c/webcomponents/issues/762#issuecomment-623367775) once custom elements are upgraded.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/762#issuecomment-689310549