Device Posture API

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.

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.

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

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

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

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

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

This specification defines the following posture values:

1. 

   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. 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.

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 update the device posture information of the document 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.

The Device Posture API defines a policy-controlled feature identified by the token "device-posture". Its default allowlist is 'self'.

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.

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.

The following concepts and interfaces are defined in [HTML]: list of the descendant browsing contexts.

The following is defined in [PAGE-VISIBILITY]: now visible algorithm.

The following is used but not defined in [FULLSCREEN]: animation frame task.

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.