Expose the input modality.

[plinehan]

I'm curious if you see any way, in the future, we'll be able to access the input modality separately from the focus-visible state. Probably best explained by an example:

We have an input text box. Inputs, by default, always have focus-visible, unlike buttons, etc. For design reasons (over which I have no control), we'd like this one input box to act more like a button... that is, only show focus when in a keyboard modality.

To get around this in focus-visible.js I modified focusTriggersKeyboardModality to return false on any input which is tagged with a special, well-known class name.

This is fine for my purposes, but if the goal here is to eventually move all of this behavior into the browser itself I don't know how I'd solve this problem. I this case, I want something like a :keyboard-modality pseudo-class, so I can write :keyboard-modality:focus rather than :focus-visible.

Curious what your thoughts are.

[Malvoz]

See related proposal for @media (key-navigation): w3c/csswg-drafts#1911

[alice]

Thanks for the issue and use case!

I wonder if, in a browser-based case, inputmode could help here. inputmode already has an option for "don't show a system keyboard" - I imagine you'd want to use that in this case, since showing a keyboard would be confusing. In that case, we'd also want to not show the focus ring.

I think there's some details to be worked out in terms of drawing a distinction between "no keyboard is showing at all" and "don't show a system keyboard", but other than that, do you think that would suit your use case?

[plinehan]

I have to admit that I hand't been thinking about virtual keyboards at all! Maybe I should.

I think you're right, though, that in this particular case we would not want a virtual keyboard to show on initial focus of the input.

To give more context, this input box is the message composer of a chat application. When a user opens a chat, we'd like to focus the input so they can compose a new message if they desire (using a hardware keyboard), but it is just as likely that they opened the chat for reading purposes, in which case showing a virtual keyboard seems aggressive. Only if they tap/click on the input would we want to show a virtual keyboard.

There is a similar rationale for not showing the focus indicator on the initial focus... again, it is just as likely that they opened the chat for reading purposes, and we don't want to call excessive attention to the message composer. The focus here is mostly for convenience.

That being said, it seems strictly more powerful to expose the keyboard modality since our use case may shift slightly vis-a-vis virtual keyboards. Maybe there's something more elegant I'm not considering.

[Malvoz]

w3c/csswg-drafts#621