Discuss use of libraries to provide window segments information

[anssiko]

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?