设备姿态 API

W3C 候选推荐草案

有关本文档的更多详细信息
此版本:
https://www.w3.org/TR/2026/CRD-device-posture-20260520/
最新发布版本:
https://www.w3.org/TR/device-posture/
最新编辑草案:
https://w3c.github.io/device-posture/
历史:
https://www.w3.org/standards/history/device-posture/
提交历史
测试套件:
https://wpt.live/device-posture
实现报告:
https://wpt.fyi/results/device-posture
编辑:
Kenneth Rohde Christiansen (Intel Corporation)
Alexis Menard (Intel Corporation)
前编辑:
Diego González (Microsoft,之前代表 Samsung)
反馈:
GitHub w3c/device-posture (拉取请求, 新议题, 开放议题)
其他资源
解释文档
Polyfill

摘要

本文档定义了一个 API,允许 Web 应用请求并接收设备姿态变化的通知。

本文档状态

本节描述本文档在发布时的状态。当前 W3C 出版物列表以及本技术报告的最新修订版本可在 W3C 标准和草案 索引中找到。

此规范已在基于 Chromium 的浏览器中实现。WebKit 和 Mozilla 尚未发布对此 规范的正式立场。

有意在此规范最终达到候选推荐阶段之前实现它的供应商应订阅 GitHub 上的存储库并参与讨论。

本文档由设备与传感器工作组作为 候选推荐草案发布,并使用 推荐 标准轨道

作为 候选推荐发布并不意味着 W3C 及其成员认可。候选推荐草案 整合了工作组打算纳入 后续候选推荐快照中的、相对于上一候选推荐的 变更。

这是一份草案文档,可能随时被其他 文档更新、替换或废弃。除作为进行中的工作外,引用本文档是不合适的。

本文档由一个依据 W3C 专利 政策运作的小组 生成。 W3C 维护着一个 任何专利披露的公开列表, 这些披露与该小组的交付物相关;该页面还包含 披露专利的说明。任何实际知悉其认为包含 必要权利要求 的专利的个人,都必须依据 W3C 专利政策第 6 节披露相关信息。

本文档受 2025 年 8 月 18 日 W3C 流程文档管辖。

1. 简介

设备姿态是指设备所处的物理位置,这可能是由传感器以及角度推导出来的。出现了新型的移动设备,它们具有某种可以改变其姿态的能力。最常见的设备类型是那些可以折叠的设备(其屏幕或围绕屏幕),使它们可以物理改变其外形尺寸。了解设备姿态的主要目的是通过响应式设计实现新的用户体验。

在上述“折叠”设备中,主要有两种不同的物理外形:具有单个柔性屏幕(无缝)的设备,以及具有两个屏幕(带缝)的设备。它们都可以围绕铰链折叠,当前规范适用于这两种类型。还应说明,无缝和带缝的设备都可以有不同的尺寸,从移动设备、平板到笔记本电脑大小。此外,还应注意,不同设备将有不同的默认方向(纵向或横向),折叠可能是垂直或水平的。

不同类型折叠设备的示意图

从通过避开折叠区域来增强网站的可用性,到为 Web 实现创新的用例,了解设备的姿态可以帮助开发人员根据不同设备定制其内容。

即使设备不是平放的情况下,内容也可以被浏览和消费,此时开发人员可能希望根据设备所处的姿态状态提供不同的布局。

2. Document 接口的扩展

以下内部槽被添加到 Document 接口。

内部槽 描述
[[CurrentPosture]] 设备的当前姿态

3. Navigator 接口的扩展

[HTML] 规范定义了 Navigator 接口,本规范对其进行扩展:

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

4. DevicePosture 接口

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

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

4.1 type 属性:获取当前设备姿态

在获取 type 属性时,用户代理必须返回 this相关 全局对象关联 Document 的 内部槽 [[CurrentPosture]] 的值。

4.2 onchange 属性:处理姿态变化

onchange 属性是用于 onchange 事件处理器事件 处理器 IDL 属性, 其事件处理器 事件类型为 "change"。

5. 姿态类型

本规范定义了以下 姿态 值:

  1. 连续姿态的示意图

    连续 姿态:连续姿态指的是“平坦”位置。这是大多数不允许不同姿态的设备的默认情况。

    包括没有折叠、铰链或类似功能的设备。

    由于硬件创新的性质,它还包括具有 双屏、可折叠、可卷曲或曲面屏幕的设备,只要它们 处于预期 Document 以平面布局 显示 的姿态。

    示例包括:

    • 在平坦、完全展开姿态下的可折叠设备。
    • 运行浏览器的可折叠设备,其窗口/部分不跨越铰链。
    • 处于平板模式并仅使用 1 个屏幕/侧面的 2 合 1 设备。
    • 不可折叠的设备。
    注意

    在某些情况下,设备可以运行多个应用程序,并处于非平坦的物理姿态,但只要浏览器不跨越多个屏幕/部分,相应的姿态就是连续的。

  2. 折叠姿态的示意图 折叠 姿态:折叠姿态是指可以物理折叠的设备。这些设备可以具有一个柔性屏幕或两个相邻的屏幕。此姿态在显示屏/部分之间形成一个不超过“平坦”位置的角度。

    示例包括:

    • 具有垂直铰链和内部屏幕的可折叠设备,处于“书本”姿态,其中内容跨越两个部分,并在 ~30° 和 ~170° 之间形成一个角度。
    • 具有水平铰链和内部屏幕的可折叠设备,处于“笔记本”姿态。
    注意

    当可折叠设备处于半折叠状态(如书本)时,实现者可能需要考虑文本方向和书写模式对布局和呈现的影响。

    例如,从右到左的语言(使用阿拉伯文、希伯来文、叙利亚文等文字的语言)以及许多东亚语言使用的垂直书写模式,其页面顺序与英文书籍相反,页码较小的页面在右侧。

    有关更多信息,请参阅中文日文韩文书写模式的差异。

在 API 中,姿态 值由 DevicePostureType 枚举值表示。

6. 设备姿态媒体查询

6.1 device-posture 媒体特性

device-posture 媒体特性通过 CSS 媒体查询 [MEDIAQ] 表示设备的姿态。所有 可导航 都反映其 顶级 可遍历姿态

值:
continuous | folded
应用于:
视觉媒体类型
是否接受 min/max 前缀:

用户代理 必须 通过 CSS 媒体查询 [MEDIAQ] 反映 Web 应用程序的应用 姿态

7. 读取设备姿态

每个 Document 实例都有一个内部槽 [[CurrentPosture]],它应在 Document 创建时初始化,否则必须在第一次 访问它们且读取其值之前 对它们进行初始化。用户 代理必须运行设备姿态 变更步骤,并将 document 设置为该 Document,将 disallowRecursion 设置为 true,以初始化它。

对于给定的 Document当前姿态派生自 当前铰链角度和屏幕方向, 以及可能的其他特定于实现的信号。

这些表格是非规范性的。

7.1 姿态值表

这些值是近似值,可能因设备而异。例如,设备平放时可能不会正好是 180°,而是介于 175° 到 185° 之间的值。设备制造商 应当 确保物理设备的姿态正确映射到本规范定义的姿态。设备制造商也可以通过 使用比铰链角度更多的传感器来确定姿态。例如,他们还可以检测键盘是否连接在屏幕的下半部分。另一个例子是检测 是否展开支架。

某些设备可能由于物理限制或设备设计而缺少一种或多种姿态,在这种情况下,设备 应当 确保所有角度和设备方向的组合(可以由 [SCREEN-ORIENTATION] 和主机操作系统锁定),以及设备特定信号,映射到定义的姿态之一。

7.1.1 折叠设备

折叠设备的姿态值
姿态 角度值
continuous < ~180°
folded ~180°

8. 算法

8.1 计算设备姿态信息

Document document 执行计算设备姿态信息的步骤如下:

  1. topLevelTraversabledocument相关 全局对象可导航顶级 可遍历
  2. 如果 topLevelTraversable. [[PostureOverride]] 为非 null, 返回 它。
  3. 返回一个 DevicePostureType 值,该值以 实现定义的方式 基于当前铰链角度 值、当前屏幕 方向, 以及可能的特定于实现的信号,根据 姿态值表确定。

8.2 设备姿态变化

当用户代理确定某个顶级 可遍历的屏幕折叠角度、 方向或设备特定信号发生变化时,它必须使用该顶级 可遍历活跃 文档运行设备姿态变更步骤

对于 Document document 和一个 可选布尔值 disallowRecursion(默认为 false), 设备姿态变更步骤如下:

  1. 如果 document可见性 状态为 "hidden",则中止这些步骤。
  2. posture 为使用 document 调用计算设备姿态 信息的结果。
  3. 如果 posture 等于 document.[[CurrentPosture]],则中止这些步骤。
  4. 用户 交互任务源上,使用 document相关 全局对象排入一个全局 任务,以执行以下 步骤:
    1. document.[[CurrentPosture]] 设置为 posture
    2. 在与 document相关 全局对象的关联 Navigator 相关联的 DevicePosture 对象上,触发一个 事件,其名称为 "change"。
  5. 如果 disallowRecursion 为 true,则中止这些步骤。
  6. 对于 document后代 可导航中的每个 descendantNavigable执行:
    1. 运行设备姿态变更 步骤,并将 document 设置为 descendantNavigable活跃 文档,将 disallowRecursion 设置为 true。

本规范定义了给定 visibility statedocument 时的以下页面 可见性变更步骤

  1. document 上运行设备姿态变更 步骤,并将 disallowRecursion 设置为 false,以 初始化它。
议题 103:避免使用页面可见性变更步骤 钩子

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

如果规范作者发送拉取请求,直接从这里向其规范中添加调用, 而不是使用页面 可见性变更步骤钩子,会更好,以确保跨规范调用顺序得到明确定义。在 撰写本文时,已知以下规范具有页面 可见性变更步骤,它们将以未指定的顺序运行:Device Posture API 和 Web NFC。[DEVICEPOSTURE] [WEBNFC]

9. 安全考虑

关于此规范,目前没有报告新的安全注意事项。但是,建议查看本文档中列出的潜在10. 隐私注意事项

10. 隐私考虑

10.1 隐私威胁类型

本节为非规范性内容。

10.1.1 跨上下文识别用户

当此 API 在同一设备上的不同浏览上下文中同时使用时,可能会将用户在这两个上下文中关联起来,形成意想不到的跟踪机制。 但是,由于姿态值通常在较长时间内保持稳定,它只能用于验证两个用户是否不相同,而不能帮助识别特定用户, 因为存在多种类型和型号的可折叠设备。

添加的熵与 pointer API 相当, 该 API 告知用户的主要输入是否为触摸类型。在设备上,当键盘可以移除/添加或激活/停用平板模式时,主要输入也可能发生变化。

这种理论攻击通过 10.2.1 数据最小化10.2.2 用户关注10.2.3 用户介导的操作 进行缓解。

10.1.2 跨域 iframe

跨域 iframe 通过此 API 获取姿态信息,因此可能会像在 10.1.1 跨上下文识别用户 中提到的那样用此信息识别用户。 同样的缓解措施也适用。

10.1.3 恶意脚本注入(用于广告或漏洞利用)

通过 iframe,恶意行为者可以注入自己的代码来访问姿势信息,并可能利用这些信息来跟踪用户。

这种理论上的攻击可以通过10.2.1 数据最小化以及姿势值本身携带的价值信息很少且在很长一段时间内保持稳定这一事实来缓解。

10.2 缓解策略

10.2.1 数据最小化

API 暴露了称为 姿态 的高级抽象,它可以是 "continuous" 或 "folded"。 不支持不同姿态的设备默认为 "continuous"。 这意味着最多增加一位熵。最多是因为揭示这一位需要用户进行显著、明确的物理操作,以改变设备姿态并触发更改。

实现可以使用多种低级信息来确定最合适的高级姿态,但通过此 API 不会暴露任何低级细节。 此外,任何精细的低级传感器读数都不存在与高级姿态状态的一对一映射。 实现可以使用例如铰链角度传感器、其他传感器、键盘是否已对接或支架是否已展开等信息,或者这些信息的任意组合, 来确定给定外形的最合适姿态。 这种抽象确保只暴露实现预期功能所需的最少信息,从而遵循数据最小化原则。

10.2.2 用户关注

只有对于每个 活跃 文档,其可见性 状态 为 "visible" 时,才会触发姿态值变更事件,如设备姿态变更步骤中所述,并且 在不满足该条件时轮询该值,将返回一个陈旧 值,因为该值仅在可见性状态为 "visible" 或刚刚变为 "visible" 时才会更新。

10.2.3 用户介导的操作

用户需要进行显著且明确的物理操作来修改设备姿态,以触发姿态更改。 显著,是因为操作必须跨过每个 姿态值表 定义的阈值; 明确,是因为底层操作系统会根据姿态变化做出相应的适应,符合用户对该操作结果的预期。

11. 可访问性考虑

Device Posture API 的主要目标是提升用户体验。应用程序基于该 API 可在三种方面对可访问性产生积极影响。
  1. 设计和开发不将内容(特别是按钮)放置在折叠/铰链区域的应用程序。由于折叠的弯曲性,使得使用手指在此区域进行交互变得困难甚至不可能。
  2. 设计和开发不在折叠/铰链区域上跨越大型连续内容(如视频或图片)的应用程序。如果设备处于折叠状态,此区域会轻微扭曲内容和颜色。
  3. 设计和开发更好地利用屏幕空间的应用程序,通过提供分屏 UI(将内容分割显示在屏幕不同部分的用户界面), 使得应用程序提供一种差异化且更具功能性的界面。
使用此 API 时,重要的是考虑以上对可访问性的机会。以下是一些具体的例子:

12. 自动化

Device Posture API 给测试作者带来了挑战,因为要全面 测试接口需要物理硬件设备。为了解决 这一挑战,本文档定义了 [WEBDRIVER2] 扩展命令,允许用户 控制所报告的设备姿态并 模拟真实设备。

为了支持下面的扩展命令及其与 8. 算法的集成,顶级 可遍历必须具有以下 内部槽:

内部插槽 描述
[[PostureOverride]] 覆盖硬件提供的当前姿态。 可能的值: 这些值不会直接暴露给脚本。

12.1 扩展命令

12.1.1 设置设备姿态

HTTP 方法 URI 模板
POST /session/{session id}/deviceposture

扩展命令将 设备姿态更改为特定的 DevicePostureType

此算法所使用的 parameters 参数的属性
参数名称 值类型 必需
posture String

远端 步骤为:

  1. posture 为从 parameters 调用 获取属性 "posture" 的结果。
  2. 如果 posture 不是字符串,则返回带有 WebDriver 错误 代码 invalid argumenterror
  3. 如果 posture 既不是 "continuous" 也不是 "folded",则返回带有 WebDriver 错误代码 invalid argumenterror
  4. topLevelTraversable当前浏览 上下文顶级 可遍历
  5. topLevelTraversable. [[PostureOverride]] 设置为 posture
  6. documenttopLevelTraversable活跃 文档
  7. 使用 document 调用设备姿态变更 步骤
  8. 返回带有数据 nullsuccess

12.1.2 清除设备姿态

HTTP 方法 URI 模板
DELETE /session/{session id}/deviceposture

扩展命令会移除 设备姿态覆盖,并将 设备姿态控制权交还给硬件。

远端 步骤为:

  1. topLevelTraversable当前浏览 上下文顶级 可遍历
  2. 如果 topLevelTraversable. [[PostureOverride]]null,则返回带有数据 nullsuccess
  3. topLevelTraversable. [[PostureOverride]] 设置为 null
  4. documenttopLevelTraversable活跃 文档
  5. 使用 document 调用设备姿态变更 步骤
  6. 返回带有 数据 nullsuccess

13. 示例

本节是非规范性的。

13.1 示例 1:姿态数据

这是一个简单的用例,将 姿态 打印到控制台上。

示例 1:响应姿态变化
navigator.devicePosture.addEventListener("change", () => {
      console.log(`The current posture is: ${navigator.devicePosture.type}!`);
    })

13.2 示例 2:设备姿态

设备正在用于视频通话网络服务。它可以折叠成笔记本姿态,当放置在平面上时可以实现免提体验。 用户代理检测到姿态后,用户界面会得到增强。类似的示例可以为内容适应任意姿态而起草。 有关其他关键场景,请参见 explainer

使用 device-posture 媒体特性和视口段媒体特性的视频通话网络服务的插图
示例 2:适应姿态的用户界面
@media (device-posture: folded) and (vertical-viewport-segments: 2) {
      body {
        display: flex;
        flex-flow: column nowrap;
      }
    
      .videocall-area, .videocall-controls  {
        flex: 1 1 env(viewport-segment-bottom 0 0);
      }
    }

13.3 示例 3:检测 device-posture 媒体特性

由于 device-posture 的有效值之一总是为真,您可以使用以下代码段来检测用户代理是否支持该媒体特性:

示例 3:检测 device-posture 特性
@media (device-posture) {
      /* 浏览器支持 device-posture 特性 */
    }
有关布尔上下文中媒体特性的更多信息,请参阅在布尔上下文中评估媒体特性

14. 一致性

除了标记为非规范性的部分外,本规范中的所有编写指南、图表、示例和注释都是非规范性的。本规范中的其他内容均为规范性。

本文档中的关键词 MUSTSHOULD 应按 BCP 14 [RFC2119] [RFC8174] 中所述进行解读,且仅当它们如这里所示以全 大写形式出现时才如此。

本规范定义了一个产品的一致性标准: 一个实现其包含接口的用户代理

A. IDL 索引

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

本节是非规范性的。

我们感谢 Diego González 作为创始编辑对 本规范做出的重大贡献,以及为本规范和设备与传感器工作组 创建视觉标识。

我们要衷心感谢 Daniel Appelquist、Jo Balletti、Michael Blix、Paul Grenier 和 Laura Morinigo 对本工作的贡献。

C. 实质性变更摘要

本节内容不具约束力。

D. 参考文献

D.1 规范性参考文献

[dom]
DOM 标准。Anne van Kesteren。WHATWG。 现行标准。URL:https://dom.spec.whatwg.org/
[HTML]
HTML 标准。Anne van Kesteren; Domenic Denicola;Dominic Farolino;Ian Hickson;Philip Jägenstedt;Simon Pieters。WHATWG。现行标准。URL:https://html.spec.whatwg.org/multipage/
[infra]
Infra 标准。Anne van Kesteren;Domenic Denicola。WHATWG。现行标准。URL:https://infra.spec.whatwg.org/
[MEDIAQ]
媒体查询第 4 级。Florian Rivoal;Tab Atkins Jr.。W3C。2021年12月25日。W3C 候选推荐标准。URL:https://www.w3.org/TR/mediaqueries-4/
[RFC2119]
RFC 中用于指示需求级别的关键字。S. Bradner。IETF。1997年3月。最佳当前实践。URL:https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
RFC 2119 关键字中大写与小写的歧义。B. Leiba。IETF。2017年5月。最佳当前实践。URL:https://www.rfc-editor.org/rfc/rfc8174
[SCREEN-ORIENTATION]
屏幕方向。Marcos Caceres。W3C。2023年8月9日。W3C 工作草案。URL:https://www.w3.org/TR/screen-orientation/
[WEBDRIVER2]
WebDriver。Simon Stewart;David Burns。 W3C。2024年10月9日。W3C 工作草案。URL:https://www.w3.org/TR/webdriver2/
[webidl]
Web IDL 标准。Edgar Chen;Timothy Gu。 WHATWG。现行标准。URL:https://webidl.spec.whatwg.org/

D.2 信息性参考文献

[clreq]
中文文本布局要求 - 中文排版需求。Fuqiao Xue;Richard Ishida。W3C。2024年7月1日。W3C 工作组说明。 URL:https://www.w3.org/TR/clreq/
[jlreq]
日语文本布局要求 日本語組版処理の要件(日本語版)。Hiroyuki Chiba;Junzaburo Edamoto;Richard Ishida;Seiichi Kato;Tatsuo KOBAYASHI;Toshi Kobayashi;Nathaniel McCully;Felix Sasaki;Atsushi Shimono;Hajime Shiozawa;Fuqiao Xue 等。W3C。2020年8月11日。W3C 工作组说明。URL:https://www.w3.org/TR/jlreq/
[klreq]
韩文文本布局和排版要求: 한국어 텍스트 레이아웃 및 타이포그래피를 위한 요구사항。Richard Ishida。W3C。2020年5月27日。W3C 工作组说明。URL:https://www.w3.org/TR/klreq/