Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: support for analog keyboards #187

Open
rektide opened this issue Jul 2, 2023 · 3 comments
Open

Request: support for analog keyboards #187

rektide opened this issue Jul 2, 2023 · 3 comments

Comments

@rektide
Copy link

rektide commented Jul 2, 2023

This is the nichest of niche interests, but I'd love a way on the web to use something like a Wooting 60HE keyboard, which is a 60% keyboard with fully analog keys.

Utterly obvious use cases:

  • variable rate scroll, depending on how much i hold down the button.
  • analog character movement in game.
  • fast/slow job through a video.

I'm happy to refile this elsewhere but nothing else seems to have the focus on continuous analog streams. Please let me know if I should redirect this ask. Or maybe this should be asked in parallel to multiple specs?

@rektide rektide changed the title Support for analog keyboards Request: support for analog keyboards Jul 2, 2023
@nondebug
Copy link
Collaborator

nondebug commented Jul 5, 2023

Exposing keyboard inputs through Gamepad API would put the user at risk. Currently, Gamepad API doesn't enforce any input focus restrictions. A page can receive gamepad inputs even if it's not focused or backgrounded. We think this is fine because gamepads aren't commonly used to enter private information like passwords, and there are known use cases where background gamepad access is desirable.

Keyboards, on the other hand, are commonly used to enter private information like passwords. The operating system uses an input focus model to give the user control over which applications receive keystroke data. A similar focus model is implemented on the web platform to prevent a page from receiving key events meant for a different page, or to prevent a page from capturing keystrokes entered into a protected field.

If we expose pressure-sensitive keyboard inputs through Gamepad API, it gives script access to keystroke data that it would not be able to receive as input events, undermining the browser's input focus model. I don't see a way around this so I think this is probably a non-starter.

@reillyeon
Copy link
Member

Agreed that adding keyboard support to the Gamepad API isn't the right solution. I would recommend moving this feature request to the UI Events specification.

@7ombie
Copy link

7ombie commented Aug 3, 2023

The Web needs a new keyboard API that permits keyboard input to be handled by workers. It cannot be a DOM API, so would need to be quite different to the current keyboard API, but this is not the place to flesh out how that might work. There was a proposal, but the scope was far too broad (it included pointer events and some MIDI stuff), and it died, and nothing has happened since on that front.

User input is generally problematic on the Web, as many APIs lack support for workers, and the main thread is often busy.

I did argue once that the Gamepad API needs to support threads, as a large percentage of videogames respect frame-perfect inputs, which cannot be handled reliably on the main thread, but frankly, that suggestion wasn't well received.

We really need our APIs to permit any user input to be handled by a worker, but that is not going to happen for the Web in any foreseeable future. It's a shame, as it really undermines the Web as a platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants