search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.46k stars 657 forks source link

[cssom-view] Proposal: Enabling new multi-display and multi-window experiences #4615

Open michaelwasserman opened 4 years ago

michaelwasserman commented 4 years ago

I'd like to raise awareness and request feedback for a couple proposals relevant to this working group. They touch on numerous aspects of the Screen and [Window](https://drafts.csswg.org/cssom-view/#extensions-to-the-window-interface) interfaces. Thanks in advance for any issues filed, or other discussion/feedback shared!

Screen Enumeration API This proposal aims to give web developers information about the set of connected physical displays, and considers additional display properties that may be useful beyond the current Screen interface.

Window Placement API The ability to open and move windows across the full set of connected displays is unstandardized and the current behavior is inconsistent between implementers. This proposal aims to give web developers standard means to manage their web content in modern windowing environments.

michaelwasserman commented 4 years ago

FYI @zcorpan

foolip commented 4 years ago

@michaelwasserman will these proposals have any effect on the existing window.screen, i.e. will the screen that object refers to ever change dynamically? I suspect not?

michaelwasserman commented 4 years ago

AFAICT, the existing window.screen object is actually already live/dynamic, ie. cached Screen objects obtained from window.screen will return updated values in response to system display changes, and even handles moving the browser windows to a different display.

My current thought is that getScreens() should return static Screen objects, the API should offer an onscreenchange event, and it may be worth considering changing the window.screen object to also be static.

Other options are certainly on the table; I'd appreciate thoughts and feedback on this open screen-enumeration issue: https://github.com/webscreens/screen-enumeration/issues/12

foolip commented 4 years ago

Thanks @michaelwasserman!

Another related consideration is if you want window.screen === window.getScreens()[0] or not. Adding that requirement pretty much forces you into live objects, while not having it raises the question of how to know that two Screen instances represent the same screen.

michaelwasserman commented 4 years ago

Per recent feedback from TAG, we'd like to get this group's thoughts on deprecating the existing window.screen object and reducing its interface to what is needed for web compatibility.

Thoughts on that or feedback on webscreens/window-placement are greatly appreciated! @foolip the proposal favors exposing static snapshots, so it explores exposing Screen.id or the 'current' ScreenInfo.