WebKit
Keyboard Lock
WebKittens
No response
Title of the spec
Keyboard Lock
URL to the spec
https://wicg.github.io/keyboard-lock/
URL to the spec's repository
https://github.com/wicg/keyboard-lock/
Issue Tracker URL
No response
Explainer URL
https://github.com/WICG/keyboard-lock/blob/gh-pages/explainer.md
TAG Design Review URL
No response
Mozilla standards-positions issue URL
https://github.com/mozilla/standards-positions/issues/196
WebKit Bugzilla URL
No response
Radar URL
No response
Description
This spec can be useful in cloud gaming use-cases for instance. I'd like to know Apple's position about supporting this spec in WebKit.
Is this being maintained? E.g., https://github.com/WICG/keyboard-lock/issues/58 (something I was wondering about as well) from 2020 is still open.
I discussed the API colleagues and we are concerned with the overall design of the API. Although inherently tied to the Fullscreen API, the integration of the APIs is not handled as gracefully as it could be. The spec itself makes reference to this issue multiple times, suggesting to developers various ways to overcome issues (e.g., call .lock() before .requestFullscreen(), which points to design flaws in the overall design). An alternative approach with better full screen integration could be explored, as is suggested in:
https://github.com/WICG/keyboard-lock/issues/58
Other concerns are normative descriptions of UI behavior, such as:
- “...overlay a message on the screen telling the user that they can Hold the Escape key to exit from fullscreen.”
- “If the key is held for 2 seconds....“
These kinds of normative requirements are overly prescriptive and browser/platform specific behavior. They may not be suitable depending on platform or browser conventions, which is also acknowledged by the specification (e.g., in the Mobile Device Considerations section). This again points to the overall design of API being very “desktop centric” (or, at times, it's OS/Windows centric).
The spec itself also points out a number of potential cross platform incompatibles, which, coupled with the ability for developers to specify their own key-lock combinations seems like it could lead to significant issues. Perhaps such things could be left up to the implementation to handle? In particular, specifying unconventional key locking combinations could lead to user annoyance, and unforeseen (by the developer) internationalization and accessibility issues.
@philn, what are your thoughts on it? Would be great to get your input to come up with a (WebKit) position and perhaps some feedback to send to the WICG.
Hi @philn, just pinging for an update. If we don't hear back we might mark this as "withdrawn"?
It would be great to get WebKit's support for this feature, since it can make fullscreen experiences a lot better: https://developer.chrome.com/blog/better-full-screen-mode/.
@tomayac I think that would require someone to step up and deal with the feedback that has been given. I see I filed issues in 2017 that still haven't been resolved.
It looks like no real work has been done (and hardly any comments) to any of the issues filed against this over 3 years ago. It has the appearance of a post-facto spec thrown over the wall after an implementation was done, and then dropped.
Hi @philn, just pinging for an update. If we don't hear back we might mark this as "withdrawn"?
Feel free to do that yes.
@philn @marcoscaceres Per the discussion with @annevk on the last WebKit Contributors meeting, I believe it is still worth to try implementing it based on the current spec draft under the flag. I filed a bug for implementing this feature. (CC: @jdatapple , @stwrt)
Sure, but we should fix the spec in parallel too if we can. Otherwise, it may not be possible to unflag this generally given all the issues we've identified (and a lot of code and tests may need to be re-written).
@tomayac, can you check on your side if there is resourcing to collaborate on fixing the API? It's not in a good state and we collaborate on something better.
@marcoscaceres Sure. We also think the enhancement(or clarification) in the specification is needed. We will make sure what it needs to be improved while preparing a draft implementation for the more in-depth discussion of the spec.
Right, but please don't do that in isolation (we should agree on a design and see if we can get everyone on board). If we need have a call, let's set one up. I'm worried that you will end up implementing a bunch of stuff that we won't be able to land - or you'll end up shipping a design that no one is really happy with, which will confuse developers and the ecosystem.
Mozilla has an interesting proposal that seems to address a lot of the concerns we raised above. I asked if they are willing to bring it over to the WICG.
Just to be clear, Mozilla proposes just having this as an option when calling .requestFullscreen(), which makes a lot of sense. It also tries to solve for the potential key combination foot guns.
It also makes the API super simple: it reduces the whole thing down to a single dictionary member, which is really elegant.
@marcoscaceres The Mozilla proposal looks good to me but we will review internally and share the feedback.