API design for a single multi-screen boolean

[michaelwasserman]

This issue considers the value and design of a particular limited-information query:
"Does this device have multiple screens that might be viable for Window Placement?" -> yes / no

This single bit could inform sites whether to advertise advanced multi-screen functionality in their UIs, and whether requesting additional multi-screen information (with a greater privacy barrier) could be useful. User Agents could even expose that single boolean with no privacy barrier, minimizing prompts of single-screen users for nonexistent multi-screen information.

What do folks think about this API and some possible shapes?

1. Extend getScreens() with a dictionary argument for requesting limited info, eg:
   getScreens({multiScreen:true}) returns a promise to a dictionary {multiScreen:<result>}
   This could be extended to request other bits of limited info, but no immediate needs are known.
   This means getScreens() would always yield a dictionary, not a sequence of screens, as proposed.
2. Add a separate special-purpose function for getting this single boolean, eg:
   isMultiScreen() returns a promise to a boolean value (allowing for async permission checks)
   This is direct and allows getScreens() to continue returning a promise to a sequence of screens.
3. Add a media query for this boolean flag, eg: @media only screen and (multi-screen: true)
   This supports showing or hiding multi-screen UI elements, but doesn't support permission controls

Note: Issue #23 discusses limited API ideas, including the “more than one screen?" question.

[michaelwasserman]

Thanks to @inexorabletash for the suggestion to use a dictionary in (1) like {multiScreen:true} instead of a list of tokens, like ['multiScreen', 'colorDepth'], and for suggesting a name for (2).

Thanks to @domenic for pointing out that if getScreens() yields a dictionary of screen info, then getScreens() shouldn't yield a sequence of screens, and for also suggesting (2).

Thanks to @hober for media query idea, and for suggesting to explore more limited API shapes.

[kenchris]

Please consult our advice in https://w3ctag.github.io/design-principles/#device-enumeration

We recommend providing the ability to filter or constrain the devices that get returned.

[plinss]

It's also not clear if a multiScreen boolean is something that should be exposed (especially without permissions). Given the intersection of filtering and user permissions the user may not want to expose some screens under some conditions, so the notion of multiple screens being available can be somewhat fluid.

[michaelwasserman]

@kenchris Thanks for sharing that feedback, and I am familiar with the linked document. While it may be possible to support filters supplied by callers to constrain the devices that get returned, it would still be possible to obtain all screen information (e.g. getScreens({minWidth:10}) or getScreens({internal:true}) & getscreens({internal:false})), and I'm not sure what user privacy or developer utility benefits that yields for additional nontrivial implementer-side work. I attempted to cover this in a recent change. The updated Window Placement proposal clarifies that users and their agents can limit the exposed information (eg. rejecting promises or returning information equivalent to the existing window.screen object at their discretion), which seem like more valuable privacy protections. Please let me know if there is compelling value for supporting other less powerful API alternatives, or if the proposal could more appropriately address the underlying concerns.

@plinss It's totally fair for implementers (and their users) to decide under what circumstances to expose the proposed multi-screen boolean, and it may be reasonable to never expose this information, expose it only to some sites with explicit permission, expose it by default to (secure, etc.) sites, or use other access control techniques. The proposal simply introduces a surface where that high utility bit of information may be exposed separately from getScreens(). The resulting value and its availability could certainly change as users grant or deny access to screens, physically connect or disconnect screens, or similar; some of those circumstances may even be good cause to fire the proposed screenschange event.

Thank you both for your input, I hope I managed to address your concerns. I'm going to close this broad issue as the proposal has been updated and moved to the Window Placement repo. I welcome feedback on these or other topics there, or feel free to continue commenting here if that is more appropriate.