I agree with everyone else that this should be a fullscreen only API. In fact I’d argue that in the spec it should be taken as a parameter to requestFullSreen, with the user being prompted that the application is requesting “fullscreen with keyboard”. Having it as a variation on an existing function as opposed to a second function that is never independently toggled seems to make a lot more sense.
I agree that there do need to be some keys and combinations that can’t be cancelled and some work needs to be done to capture a common subset for various OSes as @Edward_J has started. The standard here should be what your average game would allow (as they are the most common full screen application). So OS control keys, task switchers like Alt+Tab etc would not be cancelable.
When the fullscreen API was being created there was a lot of talk about preventing clever phishing attempts that pretended to look/act like a desktop which is how we ended up with things like
requestFullScreen() rather than
Similarly I’m happy that games may well want the sort of shortcuts that my browser claims and if I’m crouching while walking backwards in an FPS I don’t want a save dialog popping up. But when I hit certain OS level key combinations I need to know it is legitimate. If a game is full screen it’s no different to me as a user as any other fullscreen game, I’d therefore want to be able to alt-tab away. There is a reason that remote desktop software does not override certain OS key combinations despite how annoying it might be at times.
Finally I suggest that rather than declaring keys to request a lock for it should just be an all or nothing request. If we are going to allow capturing higher level key combinations users need to understand when told they are in this mode what does and does not work. This massively simplifies the implementation for browsers, usage by developers and burden of knowledge for a user.