Couple to fullscreen API

[martinthomson]

It has been argued that requesting access to keys is orthogonal to fullscreen access and so an orthogonal API is the right shape for this.

This is a fine argument from a purely theoretical standpoint, but it makes communicating the status of keyboard access on the web unnecessarily complicated. You can see in the demo (only viewable in Chrome) that maintaining orthogonal states has benefits, but those benefits assume a lot about how status is communicated.

The primary benefit of orthogonality is the potential for this API to be used without fullscreen access. As that has no practical realization, I don't think that it is worth keeping under the YAGNI principle. On the contrary, as allows for the creation of a state with no concrete use, it is harmful to have.

Thus, I would propose that this use an argument to requestFullScreen() as follows:

enum FullscreenKeyboardLock { "none", "browser", "system" };
dictionary FullscreenOptions {
  FullscreenKeyboardLock keyboardLock = "none";
};

(This particular spelling assumes particular resolutions to other issues that will be raised separately.)

[garykac]

Most of the early requests for this feature wanted it to work in windowed mode.

We opted to restrict it to full-screen only because that was a safer way to get the API implemented and available., but we still receive requests for it to work in windowed mode.