Device Posture API

1. Introduction

New types of mobile devices are appearing that have some sort of folding capabilities around the screen. Hence, when the device folds, it physically can be different form factor. The main interest in knowing the posture 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 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. Extensions to the Screen interface

The [cssom-view] specification defines the Screen interface, which this specification extends:

WebIDL[SecureContext]
partial interface Screen {
  [SameObject] readonly attribute DevicePosture posture;
};

3. The DevicePosture interface

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

enum DevicePostureType {
  "no-fold",
  "laptop",
  "flat",
  "tent",
  "tablet",
  "book"
};

4. Posture modes

This specification defines the following posture values:

1. No-Fold is the posture of a device without a hinge. This is the expected value for devices that do not fold.
2. Laptop posture indicates that the device is being used as a traditional laptop, meaning one screen is placed on a more or less horizontal surface with a screen angle between 180 to 0 degrees.
3. Flat posture indicates that one screen is being placed on a more or less horizontal surface with a screen angle around 180 degrees.
4. Tent posture indicates that the edges of both screens are placed on a horizontal surface but with an angle > 180 degrees.
5. Tablet posture is when the device can turn around on its hinge all the way to have the screen back to back. The angle is considered to be around 360 degrees.
6. Book posture is when the device is used between around 50 and 160 degrees. It is generally used while being held on (not on a surface).

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

5. Device Posture Media Queries

The 'device-posture' media feature

The device-posture media feature represents, via a CSS media query [MEDIAQ], the posture of the device. This media feature applies to the top-level browsing context and any child browsing contexts. Child browsing contexts reflect the posture of the top-level browsing context.

Value:

no-fold | laptop | flat | tent | tablet | book

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

6. Reading the posture

All documents have a current posture. Both of them 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 them.

For a given document, the current posture is derived from the current hinge angle and the current screen orientation.

These tables are non-normative.

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) maps into one of the defined postures.

The posture values table shows how the posture values are derived depending on the orientation of the fold:

Horizontal Fold

Devices with a horizontal fold are the ones for which in their main form factor, the folding occurs from side to side, across the screen(s).

Vertical Fold

Devices with a vertical fold are the ones for which in their main form factor, the folding occurs from top to bottom, across the screen(s).

7. Algorithms

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

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

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.

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