Is navigator the right place?

[alice]

Coming here from the TAG review thread.

We had some doubts as to whether navigator was the right place for the virtualKeyboard object to live, as opposed to window. What was the reasoning behind this choice?

[BoCupp-Microsoft]

In Chromium browsers, navigator.keyboard is an instance of the Keyboard object. It seemed complementary to create a navigator.virtualKeyboard rather than place it on window.

If you ask, why is there a keyboard property on navigator, then I'm less certain of the reason, but I suspect its because Navigator is home to other "device or system-like" APIs. Examples include: Gamepad API, Media Input Devices, and WebUSB.

Maybe you knew all that already and your point is that a VirtualKeyboard is not a device attached to the system and in that sense is not like the other interfaces exposed on Navigator. In that case I'd point out that Navigator by definition is the place to represent the state of the user agent, and VirtualKeyboard describes whether the user agent is in a state that could shrink the visual viewport when the virtual keyboard comes up. Similar examples of system-wide, software state exposed by Navigator include clipboard, languages, and many others.

Trying to come up with a general rule for when to put an instance of an object on Navigator: I think it is when the interface you're exposing controls access to a system-wide resource and any changes in the state of that resource affects all realms.

Let me know if you disagree with this thinking. I don't see any rules that declare when you should add to the Navigator interface. I can open a design principles bug if you like to create guidance that explains why so many "system-level" APIs have been gathered there.

[snianu]

TAG reviewed the explainers and the discussions we had in TPAC and supported the proposal.