The spec currently lacks a "posture" definition. Given this term can mean many things, we should explicitly define this term in the context of this specification.

The spec has definitions for "current posture" and "posture mode".

As the DevicePosture interface has now a member called type, we may want to rename posture modes to "posture types" for consistency.
What do you folks think about it?

interface DevicePosture : EventTarget {
  readonly attribute DevicePostureType type;
  ...
};

ACTION: @darktears and @kenchris to add some text clarifying that posture may be derived from sensors in addition to the angle.

via https://www.w3.org/2021/02/24-webscreens-minutes.html#a01

From blink-dev thread: https://groups.google.com/a/chromium.org/g/blink-dev/c/prHGPxF62i4

"Second, screen fold changes (either via onchange or polling) are an ephemeral fingerprinting vector. Given this API is meant for responsive design, we recommend limiting it to visible browsing contexts. I see section 7.2 does constrain onchange for UX reasons. It should also be listed under “Security and Privacy considerations”. The mitigation should also be applied to other ways to query the property, such as polling. (Perhaps defer all updates to the page’s copy of the state until visible, not just the onchange event, or leave the APIs and CSS queries unavailable to hidden pages altogether.)"

It's been discussed renaming the spec to Screen Fold. Lose the Angle bit.

Considering a CSS block like this :

@media all and (screen-fold-posture) {}

or

@media all and not (screen-fold-posture) {}

What the UA should return according to the following cases?

• Device does not support posture changes
• Device support posture changes but in which scenario/posture we should evaluate the MQ to true or false?

-default values?
-other alternatives?

See w3c/page-visibility#73
Most of the page visibility spec is moving into the HTML Spec (see whatwg/html#7153), and calls are to be made explicitly instead of the "hook" (external-now-visible-algorithm).

Since this spec appears to rely on this ref, opening this issue to track switching to being called directly.

This could include:

• a device with a screen that physically folds (aka foldable device)
• a device with two internal screens separated by a physical hinge (aka dual-screen device)

The prose suggest both are considered, so it'd be good to make this clear in the introduction.

https://diek.us/fold-angle/#introduction

You could link to the polyfill and/or explainer from the spec header using https://github.com/w3c/respec/wiki/otherLinks to make these complementary resources more visible.

Support for single/multi-Screen folds, off-center folds, and multiple folds in a single Screen.
These questions arise from discussion on w3c/window-management#35 and relate to #37

The proposed shape of exposing a single Fold (angle, orientation, and change events) within a Screen seems to indicate that a foldable screen is exposed as a single Screen interface object. However, the proposal notes relevance of "devices with a single flexible screen (seamless), and devices with two screens (with seam)".

I'd like to better understand how this API might handle:

1. Folds positioned on a seam between two Screens
2. Folds positioned off-center within a single Screen, or folds between asymmetric Screens (related to #37)
3. Multiple folds in a single Screen (e.g. 3+ columns, or even orthogonal/overlapping folds within a Screen?)

Please also note the relevance of the proposed Window Segment Enumeration API
Let's seek compatibility between proposals and support forthcoming screen paradigms! I hope we can discuss plans/compatibility in advance of TPAC 2020 or as a Second Screen CG topic; thanks!

In the example 2, the draft mention the following:
@media (device-posture: folded) and (screen-spanning: single-fold-vertical) { ... }

The screen-spanning is outdated and should be replaced with vertical-viewport-segments:1, same for flex: 1 1 env(fold-bottom); since the newly updated CSS viewport segments media query.
Anyway, we received some feedback from developers that it can be confusing because it looks like vertical-viewport-segment (screen-spanning in this case) it's part of the current Device Posture API but it's not. Therefore the other fix would be to remove it.
Thoughts?

Some editors and implementers of the Screen Fold API attended the Second Screen WG/CG Virtual meeting to discuss this API. During that meeting that group made the following resolution for DAS WG consideration:

RESOLUTION: Drop ScreenFold.angle from the Screen Fold API first version (for DAS WG consideration)

https://www.w3.org/2021/02/24-webscreens-minutes.html#r01

This recommendation was primarily motivated by the following observations:

• need to focus on the most valuable use cases first,
• implementability considerations,
• privacy and security considerations,
• currently unresolved performance implications of exposing an angle in a CSS media query

I'd like to solicit feedback on this issue whether there are any concerns in scope-limiting the first version of this spec as proposed.

Hearing no concerns, I'd give the editors a mandate to start crafting a PR to remove the angle related API surface from the spec and align the prose with this change.

Once this spec update is complete, I suggest the group aims to publish an updated Working Draft (maybe by the end of Q1 to have a milestone) to inform the broader community of this development.

Yesterday Microsoft announced a new device that sets difference "postures" even though the screen itself doesn't really change, fold nor physically change (see image below).

This got me thinking into the concept and functionality of the device posture API itself, and its relation to these new types of "semantic" postures, and how we should support them. It is becoming increasingly common to have desktop OSs that react to when a device is being used in conjunction to a keyboard (normal laptop) and when it is being used like a tablet (with touch). Generally these changes correspond to spacing out the UI, and I think it would be really interesting to have something similar for websites.

I want to open discussion on these type of "semantic postures" to be included into the API, since I think more and more we realize that a device posture is a lot more than just applicable to foldable screens and dual screen devices.

Think about a video streaming web that when you browse to it you get the normal traditional website, but when you set your device in a "studio", "playing", "consume", "create" (whatever the name it ends up with, I am interested in the action and posture the device is in) it enhances the layout by maybe making the controls bigger, spacing them out and hiding unnecessary menus.

@media (device-posture: studio) { //adds more padding and margins and hides UI elements }

To elaborate a bit more, I think "continuous" doesn't really make the cut when it comes to device posture as for example, the device listed above, and many other 2-in-1s would all fall in the same pocket, and it would be a missed opportunity to provide layouts with better accessibility and usability.

@xfq completed renaming main branches of W3C GitHub repositories for this group.

For this repo we've now defaulted to gh-pages.

Do we want to use main for the source and deploy to gh-pages similarly to other spec repos?

Regardless, I think master branch is now stale and can be deleted, @xfq?

@kenchris for preference.

Section 8.2 is marked as non-normative summary of "some of the mitigation strategies specified in the normative sections of this specification." Would you add links back to the normative text for each mitigation?

Ideally, please also split security and privacy concerns into separate sections, as requested in the current questionnaire.

After having a chat with a bunch of folks, I am suggesting that we rename the spec to Device Posture API and move angle (animation) use-cases elsewhere.

This would fix #45 so we can move on.

Also we have heard that there is interest in postures that don't solely depend on the angle but also on other things like primary input type, so handles cases like table top:

Also, it is expected that devices will be release with at least two folds which means the user needs to know where the fold is, so it might make more sense if this was part of Window Segments API.

An accessibility review was requested of the APA as part of our role in performing horizontal review of W3C documents for accessibility concerns. The Device Posture APA was reviewed by APA member Paul Grenier who proposed the following comments that were approved by the group.

1. Per previous discussions, the group would prefer to see summary accessibility considerations organized under a heading at the same level as Security and Privacy Considerations.
2. In the Accessibility Considerations section, the group would like to see an extrapolation of 1.3.4 Orientation https://www.w3.org/WAI/WCAG21/Understanding/orientation.html applied to device posture until it can be addressed in those documents. For example, "Content does not restrict its view and operation to a single display orientation https://www.w3.org/TR/screen-orientation/ or single device posture https://www.w3.org/TR/device-posture/#posture-modes, unless a specific display arrangement is essential https://www.w3.org/WAI/WCAG21/Understanding/orientation.html#dfn-essential

Important info

• URL to affected spec: https://w3c.github.io/device-posture/
• ReSpec version: 26.8.12
• I did a "hard refresh", but it's still busted.

Description of problem

ReSpec doesn't seem to support automatically linking to plural forms.

In https://w3c.github.io/device-posture/#reading-the-posture , the "document" links work, but the "documents" link doesn't seem to work. The error is:

Couldn't match "documents" to anything in the document or in any other document cited in this specification: cssom-view, dom, feature-policy, fetch, html, infra, permissions, screen-orientation, url, webidl. Learn more about this error or see how to cite to resolve the error. Occurred at: 1. (Plugin: "core/xref").

If a device has a vertical hinge, like the Galaxy Fold, the way the postures are interpreted (dependant mostly on portrait and landscape) vary from a device with a horizontal hinge like the Galaxy Flip Z.

-Should different (non-normative tables) be recommended based on this?

As @nicjansma mentioned in the AC review of the WG charter (W3C member-only link), "device posture" is already a well-established term of art that does not relate to the physical orientation or configuration of a device (foldable or otherwise). See, e.g.,

• https://help.zscaler.com/z-app/about-device-posture
• https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-access-policy-manager-per-request-policies/implementing-device-posture-checks/overview-device-posture-checks.html
• https://developers.cloudflare.com/cloudflare-one/identity/devices
• https://www.oreilly.com/library/view/cisco-ise-for/9780133103632/ch15.html
• https://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.0/user/guide/nac.html
• https://learn.akamai.com/en-us/webhelp/enterprise-application-access/eaa-device-posture-guide/GUID-4E5EB1C2-1190-4F21-8EE3-E09642B97D00.html

Should we change the spec name (again)?

/cc @diekus @kenchris

We need to add more demos/examples in the explainer to explain the type of UX changes that a posture change will trigger.

There are some case scenarios where posture depends on the device orientation. For example, if a device is with the posture "laptop" then the browser doesn't identify/support the same way if it's portrait or landscape. In order to identify the posture, developers should check the device model or rely on media queries. Another case scenario is when browsers have multiwindow or popup mode, therefore the fold position will not always be the center of the screen but the posture is still relevant, same thing would apply for devices with more than one fold.
Should the spec add a fold position to prevent this or just rely on media queries?

Polyfill should be updated to device-posture, it still refers to the old screen fold API.

To do:

• Update text
• Update links
• Update functionalities

Now that the specification only covers the posture it seems weird to have the main entry point of the API to be in the Screen interface.

I strongly think we should move it to another place like window or window.navigator. The thinking is that there is only a single posture at a given time and it's not dependent on the screen.

What does sound best to you folks?

• window.navigator.posture

• window.posture which is basically posture

I strongly think that it we land into a generic object like navigator or window we should rename the entry point from posture to device_posture.

We can extend this

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

with

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.

@anssik

From TPAC 2021 the question came regarding being able to identify when a device is being used in a posture that enables drawing. At the moment it is possible to detect when a device is being used primarily with touch input, but there is no way of identifying if pen is present.

In places like [110-180[

[110° - 180°[

First, thank you for working on this!

Since it's in the draft Devices and Sensors Working Group Charter, I think we can move the repo to W3C space (I can help with that) and work on it as an editor's draft of the Devices and Sensors Working Group. After the new charter is approved, we can publish a First Public Working Draft.

/cc @anssiko @reillyeon

As I'm working on the implementation of the spec inside Chromium (see WIP that I uploaded in https://chromium-review.googlesource.com/c/chromium/src/+/2985142/) it seems clear to me that navigator.devicePosture.type won't work.

On Android and Windows at the moment the posture is derived from the fold angle. In the future we may or not have a dedicated API to query the posture directly but that's what we have for now. On Android it means that we need to fetch the hinge angle from the OS and that's an async operation. On Windows there isn't any API to fetch the hinge angle but so far the foldable devices shipping expose a custom sensor that is basically exposing the hinge angle as well. Similar to Android this is a async operation that may not return immediately. We need to first ask the OS access to the sensor and then wait the readings. This is extremely similar to the generic sensors btw.

So I suggest we change navigator.devicePosture.type to something else with a Promise that we can resolve when the browser have the first information to be able to compute the posture.

@kenchris

I love the logos, but they are preventing us from auto-publishing the spec. We (W3C) generally only add additional logos if we are working with other another standards organization.

Might need screen orientation spec changes, so need to talk to Marcos

Going off the proposal I'm wondering how the current spec could handle multiple displays that aren't direct mirrors of each other. Such as a slide out display or a displays with different orientation from the parent (eg. the lg wing concept).

Some questions:

• Can the posture queries be chained to target a specific display?
• Are viewports returned per 'screen'?
• Does the spec address scroll behavior to allow independent scrolling windows?

Not sure if the format of the media query for the screen-fold-angle documentation is correct. Need to get a reference to the 'angle' value and check if it complies with references. @kenchris

The "Commit history" link in https://w3c.github.io/screen-fold/ is broken.

To fix it, we can either change our default branch to gh-pages, or add a branch property to the ReSpec config.

It is default

It is hard to know what type to use for the environment variable.

seems to make a lot of sense, and that can be used with something like transform: skew(90deg) but I don't see how to convert that to say pixels for moving animations.

CSS calc can only divide and multiply with integer numbers and I don't see any way to convert deg to an integer or <length> value

Not book or laptop according to the below:

Thread in blink-dev: https://groups.google.com/a/chromium.org/g/blink-dev/c/prHGPxF62i4

"First, we’re concerned about the fold.angle property, as that seems a high entropy fingerprinting surface. The specification mentions this, but leaves it to the implementer and does not touch on the level of precision and anonymization the API is trying to achieve. (The suggestions of lowering resolution and fuzzing are really two strategies for the same thing.)"

"Do you have specific use cases that need the full angle information? The spec has an example of angle-driven animations, but that already seems incompatible with the resolution/fuzzing mitigation it suggests. It seems this could use more exploration into use cases and how to balance them with privacy requirements."