Device Posture API

W3C Working Draft

More details about this document
This version:
https://www.w3.org/TR/2024/WD-device-posture-20240310/
Latest published version:
https://www.w3.org/TR/device-posture/
Latest editor's draft:
https://w3c.github.io/device-posture/
History:
https://www.w3.org/standards/history/device-posture/
Commit history
Implementation report:
https://www.w3.org/wiki/DAS/Implementations
Editors:
Diego González (Microsoft, formerly on behalf of Samsung)
Kenneth Rohde Christiansen (Intel Corporation)
Alexis Menard (Intel Corporation)
Feedback:
GitHub w3c/device-posture (pull requests, new issue, open issues)
Additional resources
Explainer
Polyfill

Abstract

This document specifies an API that allows web applications to request and be notified of changes of the posture of a device.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

Implementors need to be aware that this specification is extremely unstable. Implementors who are not taking part in the discussions will find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation phase should subscribe to the repository on GitHub and take part in the discussions.

This document was published by the Devices and Sensors Working Group as a Working Draft using the Recommendation track.

Publication as a Working Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

The device posture is the physical position in which a device holds which may be derived from sensors in addition to the angle. New types of mobile devices are appearing that have some sort of capabilities that allow them to change their posture. The most common types of devices are the ones that can fold (their screen or around their screen), allowing them to physically alter their form factor. The main interest in knowing the posture of a device is to enable new user experiences with responsive design.

Among the described "folding" devices, there are mainly two different physical form factors: devices with a single flexible screen (seamless), and devices with two screens (with seam). They can both fold around a hinge, and the current specification applies to both types. It should be clarified as well that both seamless and (devices) with seam can be of different dimension ranging from mobile and tablets to laptop sizes. It should also be noted that different devices will have different default orientations (portrait or landscape), and that the fold might happen in a vertical or horizontal way.

drawing of different type of foldable devices

From enhancing the usability of a website by avoiding the area of a fold, to enabling innovative use cases for the web, knowing the posture of a device can help developers tailor their content to different devices.

Content can be consumed and browsed even when the device is not flat, in which case the developer might want to provide a different layout for it depending on the posture state in which the device is being used.

2. Internal slots

The following internal slots are added to the Document interface. As it name implies, it will house the value of the current posture the device is

Internal slot Description
[[CurrentPosture]] The current posture.

3. Extensions to the Navigator interface

The [HTML] specification defines the Navigator interface, which this specification extends:

WebIDL[SecureContext, Exposed=(Window)]
partial interface Navigator {
  [SameObject] readonly attribute DevicePosture devicePosture;
};

4. The DevicePosture interface

WebIDL[SecureContext, Exposed=(Window)]
interface DevicePosture : EventTarget {
  readonly attribute DevicePostureType type;
  attribute EventHandler onchange;
};

enum DevicePostureType {
  "continuous",
  "folded"      
};

4.1 The type attribute: Get current device posture

When getting the type attribute, the user agent MUST return the value of this's relevant global object's associated Document's internal slot [[CurrentPosture]].

4.2 The onchange attribute: Handle posture changes

The onchange attribute is an event handler IDL attribute for the onchange event handler, whose event handler event type is "change".

5. Posture types

This specification defines the following posture values:

  1. drawing of the continuous posture

    Continuous posture: The continuous posture refers to a "flat" position. This is the default case for most devices not allowing different postures.

    It includes devices with no folds, hinges or similar capabilities.

    Due to the nature of hardware innovation, it also includes devices with dual, foldable, rollable or curved screens, as long as they are in a posture where the document is expected to be displayed with a flat layout.

    Examples of these are:

    • Foldable device in a flat, fully unfolded posture.
    • Foldable device running the browser in a window/section that does not span across the hinge.
    • 2-in-1 device in tablet mode using only 1 screen/side.
    • Devices that do not fold.
    Note

    In some cases, devices can run several apps and be in a physical posture other than flat, but as long as the browser does not span through several screens/sections, the corresponding posture is continuous.

  2. drawing of the folded posture Folded posture: The folded posture refers to devices that can physically fold. These devices can have one flexible screen or two adjacent screens. This posture forms an angle between the displays/sections that does not exceed a 'flat' position.

    Examples of these are:

    • Foldable device with a vertical hinge and internal screens being used in a 'book' posture, where the content spans through both sections and forms an angle between ~30° and ~170°.
    • Foldable device with a horizontal hinge and internal screens being used in a 'laptop' posture.

In the API, the posture values are represented by the DevicePostureType enum values.

6. Device Posture Media Queries

6.1 The 'device-posture' media feature

The device-posture media feature represents, via a CSS media query [MEDIAQ], the posture of the device. All navigables reflect the posture of their top-level traversable.

Value:
continuous | folded
Applies to:
visual media types
Accepts min/max prefixes:
No

A user agent MUST reflect the applied posture of the web application via a CSS media query [MEDIAQ].

7. Reading the posture

Every instance of Document has an internal slot [[CurrentPosture]], which should be initialized when the document is created, otherwise they MUST be initialized the first time they are accessed and before their value is read. The user agent MUST run the device posture change steps with the document and true to initialize it.

For a given document, the current posture is derived from the current hinge angle and the current screen orientation, and potentially other implementation-specific signals.

These tables are non-normative.

7.1 Posture values table

The values are approximations and might differ per device. For instance, a device might not yield exactly 180° when laying flat, but instead values ranging from 175° to 185°. Device makers SHOULD make sure that the physical device postures map correctly to the postures defined by this specification.

Some devices might also lack one or more of the postures due to physical constraints or device design, in which case the device SHOULD make sure that all combinations of angles and device orientation (which can be locked by [SCREEN-ORIENTATION] and host OS), as well as device specific signals, maps into one of the defined postures.

7.1.1 Foldables

Posture values for foldable devices
Posture Angle value
continuous < ~180°
folded ~180°

8. Algorithms

8.1 Calculating the device posture information

The steps to calculate the device posture information of a Document document are as follows:

  1. Return a DevicePostureType value determined in an implementation-defined way based on the current hinge angle value, current screen orientation, as well as potential implementation-specific signals, according to the posture values table.

8.2 Device Posture change

When the user agent determines that the screen(s)' fold angle, orientation or device-specific signals have changed for a top-level traversable, it MUST run the device posture change steps with the top-level traversable's active document.

The device posture change steps for a Document document and an optional boolean disallowRecursion (default false) are as follows:

  1. If document's visibility state is "hidden", then abort these steps.
  2. Let posture be the result of invoking calculate the device posture information with document.
  3. If posture is equal to document.[[CurrentPosture]], abort these steps.
  4. Queue a global task on the user interaction task source with document's relevant global object to perform the following steps:
    1. Set documet.[[CurrentPosture]] to posture.
    2. Fire an event named "change" at the DevicePosture object associated with document's relevant global object's associated Navigator.
  5. If disallowRecursion is true, abort these steps.
  6. For each descendantNavigable of document's descendant navigables:
    1. Run the device posture change steps with descendantNavigable's active document and true.

This specification defines the following page visibility change steps given visibility state and document:

  1. Run the device posture change steps on document.
Note
Issue 103: Avoid using the page visibility change steps hook

From https://html.spec.whatwg.org/#update-the-visibility-state

It would be better if specification authors sent a pull request to add calls from here into their specifications directly, instead of using the page visibility change steps hook, to ensure well-defined cross-specification call order. As of the time of this writing the following specifications are known to have page visibility change steps, which will be run in an unspecified order: Device Posture API and Web NFC. [DEVICEPOSTURE] [WEBNFC]

9. Security and Privacy considerations

The Device Posture API exposes a posture determined from the hinge angle value and other sensors.

Typical sensor readings are sent at a constant frequency to whomever is listening to its readings. However the fold angle only communicates its value when the hinge is manipulated by the user. Variations in the angle’s readings and posture calculation, as well as event dispatching frequency offer a possibility of fingerprinting to identify users. User agents may reduce this risk by limiting or coalescing events when exposing this information to web developers. Users don’t constantly adjust the angle, so the fold angle value is changing in bursts: the events may be dispatched at a very low frequency most of the time and fire at a high frequency when the device is being opened or closed. In order for the events to be dispatched, the content must be on the foreground and visible to the user. Because the API does not directly expose the raw angle values, but a more abstract posture with fewer possible states, fingerprinting possibilities are more limited.

If the same code using the API can be used simultaneously in different window contexts on the same device it may be possible for that code to correlate the user across those two contexts, creating unanticipated tracking mechanisms.

9.1 Types of security and privacy threats

This section is non-normative.

9.2 Mitigation Strategies

This section is non-normative.

This section gives a high-level presentation of some of the mitigation strategies specified in the normative sections of this specification.

9.2.1 Secure Context

Posture value readings are explicitly flagged by the Secure Contexts specification as a high-value target for network attackers. Thus all interfaces defined by this specification or extension specifications are only available within a secure context.

9.2.2 Focused Area

Posture value readings are only available for active documents whose origin is the same origin-domain with the currently focused area document.

This is done in order to mitigate the risk of a skimming attack against the browsing context containing an element which has gained focus, for example when the user carries out an in-game purchase using a third party payment service from within an iframe.

9.2.3 Visibility State

Posture value change events are only fired for active documents whose visibility state is "visible", and polling the value while that is not the case, will return a stale value as the value is only updated while the visibility state is "visible" or just changed to "visible".

10. Examples

This section is non-normative.

10.1 Example 1: Posture data

This is a simple use case of the posture being printed on the console.

Example 1: React to poster change
navigator.devicePosture.addEventListener("change", () => {
  console.log(`The current posture is: ${navigator.devicePosture.type}!`);
})

10.2 Example 2: device-posture

The device is being used for a video call web service. It can be folded into the laptop posture to enable a hands-free when placed on a surface. The UA detects the posture and the UI is enhanced. Similar examples can be drafted for content to adapt to any posture. See the explainer for other key scenarios.

An illustration of a video call web service that uses the device-posture media feature and the viewport segment media feature
Example 2: Adapting UI to posture
@media (device-posture: folded) and (vertical-viewport-segments: 1) {
  body {
    display: flex;
    flex-flow: column nowrap;
  }

  .videocall-area, .videocall-controls  {
    flex: 1 1 env(viewport-segment-bottom 0 0);
  }
}

10.3 Example 3: Feature detection of device-posture media feature

As one of the valid device-posture values will always be true, you can use the following snippet to detect whether a user agent supports the media feature:

Example 3: Feature detect the device-posture
@media (device-posture) {
  /*The browser supports device-posture feature*/
}
For more information about media features in a boolean context please refer to Evaluating Media Features in a Boolean Context.

11. Dependencies

The following concepts and interfaces are defined in [SCREEN-ORIENTATION]: current screen orientation as represented by the OrientationType enum.

The following is defined in [MEDIAQ]: Evaluating Media Features in a Boolean Context.

12. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MUST and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This specification defines conformance criteria for a single product: a user agent that implements the interfaces that it contains.

A. IDL Index

WebIDL[SecureContext, Exposed=(Window)]
partial interface Navigator {
  [SameObject] readonly attribute DevicePosture devicePosture;
};

[SecureContext, Exposed=(Window)]
interface DevicePosture : EventTarget {
  readonly attribute DevicePostureType type;
  attribute EventHandler onchange;
};

enum DevicePostureType {
  "continuous",
  "folded"      
};

B. Acknowledgments

This section is non-normative.

We would like to offer our sincere thanks to Daniel Appelquist, Jo Balletti, Michael Blix, Alexis Menard and Laura Morinigo for their contributions to this work.

C. References

C.1 Normative references

[dom]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[MEDIAQ]
Media Queries Level 4. Florian Rivoal; Tab Atkins Jr.. W3C. 25 December 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/mediaqueries-4/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[SCREEN-ORIENTATION]
Screen Orientation. Marcos Caceres. W3C. 9 August 2023. W3C Working Draft. URL: https://www.w3.org/TR/screen-orientation/
[webidl]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/