I’ve done a similar “experiment” called focus-source for pretty much the reasons outlined in the article - by which I’m agreeing that there is a real need for this.
If I understood this correctly, the
interaction-modality) MediaQuery is supposed to change immediately whenever I change my mode of input (say, type something with my keyboard “keyboard”, then click something with my mouse “pointer”). That means that a focus-style would not be “sticky” and that may lead to confusing UI.
In my focus-source experiment I identified 3 modalities (I called it “interaction-type”): keyboard, pointer and script. The reason for “pointer” was - as has been pointed out by hexalys - that
:focus needs to remain the default style for backward compatibility reasons. My applications usually focus a container/wrapper to act as a sequential focus navigation starting point, so I added “script” to allow the CSS to identify “focus set by application”.
Hexalys hinted at
assisted-focus to provide the information if some non-document-accessible styling was being applied by an AT. I think that could/should be what
:-moz-focusring is about.
I don’t like the MediaQuery idea very much. I’d have preferred a simple pseudo-class
:keyboard-focus (that does not change while an element has focus). But the MQ would play nicely with
:focus-within, where a simple pseudo-class would not.
I’m not very fond of the idea to define “keyboard-relevant input elements” (as the polyfill shows) - considering custom elements. The
supports-modality="keyboard" attribute is technically not necessary, as anyone could achieve the same effect with current CSS functionality. Also using an attribute like that is limiting to single values - what happens when this proposal is extended to support voice input? Do we want to foster multi-value attributes like
I had trouble following the proposal and discussion because I was centered altering
:focus styles, rather than “generically dealing with input modes”. I think the former - influencing focus styles - is a problem with a simple enough solution. Dealing with “interaction modality” in terms of, say, a FPS (First Person Shooter), is quite a different beast. Is there only one mode, or can keyboard and pointer be used simultaneously? is the mode constantly switching back and forth between keyboard and pointer if I use the mouse to aim, but the space-key to shoot? Is this even relevant to 95% of web sites/applications? I have all sorts of problems wrapping my head around this.