Intent to Prototype: Window Segments Enumeration API

[Daniel Libby]

Contact emails dli...@microsoft.com Explainer

https://github.com/webscreens/window-segments/blob/master/EXPLAINER.md Design docs/spec

https://docs.google.com/document/d/1Bm1gDRcCyObQTrYkX_kZVDAhZeMq73Ns7MEliUWu7Wk/edit?usp=sharing TAG review https://github.com/w3ctag/design-reviews/issues/492 Summary Add a JavaScript API that allows web content to query logical separation of the layout viewport, in order to enlighten content to this information (i.e. by providing a split view, etc.) Motivation As new classes of devices (foldable, dual screen) come to market, web developers are interested in building layouts/experiences that are optimized for scenarios where the browser window has multiple logical segments. In addition to declarative APIs, an imperative API can be used by authors to solve more complex use cases. 

Risks

Interoperability and Compatibility

Main interoperability risk is lack of other browsers' implementation. However, fallback (no API available) would result in a site that works as it does today.

Minimal compatibility risk - the new API is additive and shouldn't have much compatibility concern.

Firefox: No public signals

Safari: No public signals

Web developers: positive

Note that there are a few other in-progress proposals that are related, but expose separate concepts. Calling these out here for completeness:

- Presentation API allows developers to target a secondary screen and place content (by opening a new window in single UA mode) on that screen. 

           - Screen Enumeration API provides information about the physical screen configuration. This is different than window segments, which describe the logical layout segments of the current window. Additionally, for some devices, the segmentation may not cross physical displays (i.e. a foldable device that only exposes a single display).

           - Window Placement API is useful in multi-window scenarios on multiple screen devices, but is also used to target placement of new windows, not describing the state of a window spanned across logical segments.

 

Ergonomics

There is a similar proposal for CSS primitives to expose this information declaratively, that will expose similar information (see https://groups.google.com/a/chromium.org/d/msg/blink-dev/KsPRO3hkOGw/md4jgIAaAgAJ). Developers may end up using these in tandem. 

Activation

No perceived risks.

A polyfill is available, however it is for specific form factors, and thus not comprehensive.

Debuggability

This area is still in its early stages, and as such the underlying operating systems’ platforms are still under development, in terms of how this information is exposed (e.g. Android support library is planning on exposing a concept of DisplayFeature). Due to this, we are working with the Microsoft Edge DevTools team to provide an emulation solution 

integrated into the Chromium devtools, in order to initially light up this API for developers.

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Still TBD as we prototype and experiment. It's unclear whether developers would target desktop scenarios where windows span multiple displays. The main Is this feature fully tested by web-platform-tests? No, part of prototyping this feature will include coming up with a plan to integrate support for emulation into wpt. Link to entry on the Chrome Platform Status https://chromestatus.com/features/5170498990243840