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

@othermaciej
> One point I am confused about: `control` was described in [#762 (comment)](https://github.com/w3c/webcomponents/issues/762#issuecomment-557488222) as a Safari-specific distinction, but per [#762 (comment)](https://github.com/w3c/webcomponents/issues/762#issuecomment-484461545) , it seems like Chrome would care about this distinction too, at least on macOS.

[My older comment](https://github.com/w3c/webcomponents/issues/762#issuecomment-484461545) was incorrect. Chrome doesn't respect "Full Keyboard Access" setting. [crbug.com/119125](https://bugs.chromium.org/p/chromium/issues/detail?id=119125)

@alice 
> Regarding "editable", does that boil down to text-editable? If that is the case, could we combine this with the hinting we use for `:focus-visible`, which in practice is equivalent to "does this show a virtual keyboard if a physical keyboard is not present"? Could we have a primitive for _that_ concept (which is very close to `inputmode`), instead of making it a separate focus type?

AFAIK, In Chrome the `control` category discussed here matches to elements which don't match to `:focus-visible`.  So the specification may mention that the category might affect `:focus-visible` selector.

I'm not sure about relationship with the virtual keyboard stuff.  Chrome and Safari don't show a virtual keyboard for focused `<select>`, but `<select>` is click-focusable, right?


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