Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
michaelwasserman opened this issue Dec 18, 2019 · 5 comments

Comments

@michaelwasserman
Copy link
Member

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
Copy link
Member Author

FYI @zcorpan

@foolip
Copy link
Member

foolip commented Dec 20, 2019

@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
Copy link
Member Author

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: webscreens/screen-enumeration#12

@foolip
Copy link
Member

foolip commented Jan 16, 2020

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants