Discuss use of libraries to provide window segments information #9
Description
Originally created by @anssiko
Content Updated by @zouhir on October, 26
The High Level Goals:
Some goals we agreed on in the 2nd-screen WG & CG (I believe none is controversial):
- We (participants) don't want to create redundant new concepts, and try to reuse each other's work as much as possible.
- We need to make sure our decisions does not sacrifice APIs usability & developer ergonomics.
Window Segments Enum API
- High level API, synchronous, returns a straight-forward array of DOMRects representing display regions browser viewport is spanned across.
- Targets "foldable" experiences only, when spanning is a semantic window mode (window manager puts you in that state).
- Our customers did not ask for "foldable" UX to be enabled in multi-mon scenario, e.g. email experience below.
Screen Enum API
- Lower level API, asynchronous API.
- Targets multi-monitor experiences, where spanning is a user action (user puts the browser window in that state).
- Can be generic & work on foldable & dual-screen.
To Discuss: Screen Enum + Client-side JS Library = Window Segments Enum API?
This was suggested at TPAC by @michaelwasserman - basically, developers can use the lower-level API and write few more lines of code to achieve Window Segments Enum API behavior or create a package that acts as a helper JS library to hide / abstract away the complexity.
Some open questions (regarding the library bit only, assuming merging the APIs in one is technically possible):
- Will that introduce friction / slow down the API adoption? Can we make a plan validate any hypothesis we have here?
- Do we have previous success stories when platform delegates such things to libraries like jQuery or lodash?
- Are we introducing something not common for developers using foldable APIs via CSS media queries and making harder to get DOMRects via JavaScript?