Reuse existing Screen interface or add something new?

[michaelwasserman]

This issue concerns the interface offered by objects returned from getScreens(). The explainer currently proposes reusing the existing Screen interface, but it may actually be better to add a new parallel interface or data structure. Some additional thoughts are discussed in the explainer's compatibility section.

Some reasons to re-use the existing interface:

• It already contains most of the information sites would want about other screens
• Reuse minimizes incompatibility between screen interfaces
• Reuse avoids redundancy in the web platform surface area
• Reuse avoids duplication of effort to support and update these structures

Some reasons to add a new parallel interface/structure:

• Better support for static snapshots via getScreens() and live objects via window.screen
• Better support for new properties via getScreens(), but not via window.screen (synchronous & permission-less)
• Makes it easier to deprecate or change the interfaces independently of each other
• Offers a new structure without legacy/deprecated/non-standard properties and resulting compatibility issues
• Sidesteps difficulties of comparing static getScreen() and live window.screen objects, since you can't overload comparison operators for objects [1]
• A simple dictionary suits static snapshots for getScreens(), and it could have a similar "shape" to window.screen just by having similar property names

[1] It might then be useful to expose a matching id on window.screen for comparison with objects returned by getScreens().

Thanks to @domenic for highlighting the difficulties/inability to successfully compare static snapshots and live objects, and for suggesting that a new dictionary might suffice instead of a new interface.

Please share your thoughts, thanks!

[kenchris]

We looked at your above list and believe that navigator.screen was kind of a mistake,

• More than one screen exists in many cases
• Good points above about async properties and permission etc

Going with the new API you should file a CSSOM View issues to ask them to deprecate the main screen object, and then cut its properties down to just what is necessary for web compat

[michaelwasserman]

I'm going to transfer this issue to the newly-consolidated window-placement repo, which now proposes a new ScreenInfo dictionary shaped similar to the existing Screen interface, and will plan to act on your guidance, thanks!

[michaelwasserman]

I commented on a related CSSOM View issue that I filed earlier; hopefully that's a good start to gather feedback, but I'm happy to file a separate issue as needed.

[michaelwasserman]

Adding a per-screen interface that follows the existing live-object Screen pattern offers developers a familiar workflow and allows synchronous access to the latest screen information in change event listeners. The API offering additional per-screen information currently inherits from the existing Screen interface, so that all window.screen attributes are also available on the corresponding new API surfaces. This seems like a reasonable pattern for now, but inheritance can probably be changed later as needed, so long as we are thoughtful about changes to the exposed attributes of each interface. Feel free to reopen this issue if there's any new feedback to consider.