Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
本文档定义了一个 API,允许 Web 应用请求并接收设备姿态变化的通知。
本节描述本文档在发布时的状态。当前 W3C 出版物列表以及本技术报告的最新修订版本可在 W3C 标准和草案 索引中找到。
此规范已在基于 Chromium 的浏览器中实现。WebKit 和 Mozilla 尚未发布对此 规范的正式立场。
有意在此规范最终达到候选推荐阶段之前实现它的供应商应订阅 GitHub 上的存储库并参与讨论。
本文档由设备与传感器工作组作为 候选推荐草案发布,并使用 推荐 标准轨道。
作为 候选推荐发布并不意味着 W3C 及其成员认可。候选推荐草案 整合了工作组打算纳入 后续候选推荐快照中的、相对于上一候选推荐的 变更。
这是一份草案文档,可能随时被其他 文档更新、替换或废弃。除作为进行中的工作外,引用本文档是不合适的。
本文档由一个依据 W3C 专利 政策运作的小组 生成。 W3C 维护着一个 任何专利披露的公开列表, 这些披露与该小组的交付物相关;该页面还包含 披露专利的说明。任何实际知悉其认为包含 必要权利要求 的专利的个人,都必须依据 W3C 专利政策第 6 节披露相关信息。
本文档受 2025 年 8 月 18 日 W3C 流程文档管辖。
设备姿态是指设备所处的物理位置,这可能是由传感器以及角度推导出来的。出现了新型的移动设备,它们具有某种可以改变其姿态的能力。最常见的设备类型是那些可以折叠的设备(其屏幕或围绕屏幕),使它们可以物理改变其外形尺寸。了解设备姿态的主要目的是通过响应式设计实现新的用户体验。
在上述“折叠”设备中,主要有两种不同的物理外形:具有单个柔性屏幕(无缝)的设备,以及具有两个屏幕(带缝)的设备。它们都可以围绕铰链折叠,当前规范适用于这两种类型。还应说明,无缝和带缝的设备都可以有不同的尺寸,从移动设备、平板到笔记本电脑大小。此外,还应注意,不同设备将有不同的默认方向(纵向或横向),折叠可能是垂直或水平的。
从通过避开折叠区域来增强网站的可用性,到为 Web 实现创新的用例,了解设备的姿态可以帮助开发人员根据不同设备定制其内容。
即使设备不是平放的情况下,内容也可以被浏览和消费,此时开发人员可能希望根据设备所处的姿态状态提供不同的布局。
以下内部槽被添加到 Document 接口。
| 内部槽 | 描述 |
|---|---|
| [[CurrentPosture]] | 设备的当前姿态。 |
WebIDL[SecureContext, Exposed=(Window)]
interface DevicePosture : EventTarget {
readonly attribute DevicePostureType type;
attribute EventHandler onchange;
};
enum DevicePostureType {
"continuous",
"folded"
};
在获取 type 属性时,用户代理必须返回
this 的相关
全局对象的关联
Document 的
内部槽 [[CurrentPosture]] 的值。
onchange 属性是用于 onchange 事件处理器的事件
处理器 IDL 属性,
其事件处理器
事件类型为 "change"。
本规范定义了以下 姿态 值:
连续 姿态:连续姿态指的是“平坦”位置。这是大多数不允许不同姿态的设备的默认情况。
包括没有折叠、铰链或类似功能的设备。
由于硬件创新的性质,它还包括具有
双屏、可折叠、可卷曲或曲面屏幕的设备,只要它们
处于预期 Document 以平面布局
显示
的姿态。
示例包括:
在某些情况下,设备可以运行多个应用程序,并处于非平坦的物理姿态,但只要浏览器不跨越多个屏幕/部分,相应的姿态就是连续的。
示例包括:
在 API 中,姿态 值由 DevicePostureType 枚举值表示。
媒体特性通过 CSS
媒体查询 [MEDIAQ] 表示设备的姿态。所有
可导航
都反映其
顶级
可遍历的姿态。
device-posture
continuous | folded
每个 Document 实例都有一个内部槽
[[CurrentPosture]],它应在
Document 创建时初始化,否则必须在第一次
访问它们且读取其值之前
对它们进行初始化。用户
代理必须运行设备姿态
变更步骤,并将 document 设置为该 Document,将 disallowRecursion 设置为 true,以初始化它。
对于给定的 Document,当前姿态派生自
当前铰链角度和屏幕方向,
以及可能的其他特定于实现的信号。
这些表格是非规范性的。
这些值是近似值,可能因设备而异。例如,设备平放时可能不会正好是 180°,而是介于 175° 到 185° 之间的值。设备制造商 应当 确保物理设备的姿态正确映射到本规范定义的姿态。设备制造商也可以通过 使用比铰链角度更多的传感器来确定姿态。例如,他们还可以检测键盘是否连接在屏幕的下半部分。另一个例子是检测 是否展开支架。
某些设备可能由于物理限制或设备设计而缺少一种或多种姿态,在这种情况下,设备 应当 确保所有角度和设备方向的组合(可以由 [SCREEN-ORIENTATION] 和主机操作系统锁定),以及设备特定信号,映射到定义的姿态之一。
| 姿态 | 角度值 |
|---|---|
| continuous | < ~180° |
| folded | ~180° |
对 Document document 执行计算设备姿态信息的步骤如下:
DevicePostureType
值,该值以
实现定义的方式
基于当前铰链角度
值、当前屏幕
方向,
以及可能的特定于实现的信号,根据
姿态值表确定。
当用户代理确定某个顶级 可遍历的屏幕折叠角度、 方向或设备特定信号发生变化时,它必须使用该顶级 可遍历的活跃 文档运行设备姿态变更步骤。
对于 Document
document 和一个
可选布尔值 disallowRecursion(默认为 false),
设备姿态变更步骤如下:
[[CurrentPosture]],则中止这些步骤。
[[CurrentPosture]] 设置为
posture。
Navigator
相关联的
DevicePosture
对象上,触发一个
事件,其名称为 "change"。
本规范定义了给定 visibility state 和 document 时的以下页面 可见性变更步骤:
来自 https://html.spec.whatwg.org/#update-the-visibility-state
如果规范作者发送拉取请求,直接从这里向其规范中添加调用, 而不是使用页面 可见性变更步骤钩子,会更好,以确保跨规范调用顺序得到明确定义。在 撰写本文时,已知以下规范具有页面 可见性变更步骤,它们将以未指定的顺序运行:Device Posture API 和 Web NFC。[DEVICEPOSTURE] [WEBNFC]
关于此规范,目前没有报告新的安全注意事项。但是,建议查看本文档中列出的潜在10. 隐私注意事项。
本节为非规范性内容。
当此 API 在同一设备上的不同浏览上下文中同时使用时,可能会将用户在这两个上下文中关联起来,形成意想不到的跟踪机制。 但是,由于姿态值通常在较长时间内保持稳定,它只能用于验证两个用户是否不相同,而不能帮助识别特定用户, 因为存在多种类型和型号的可折叠设备。
添加的熵与 pointer API 相当, 该 API 告知用户的主要输入是否为触摸类型。在设备上,当键盘可以移除/添加或激活/停用平板模式时,主要输入也可能发生变化。
这种理论攻击通过 10.2.1 数据最小化, 10.2.2 用户关注 和 10.2.3 用户介导的操作 进行缓解。
跨域 iframe 通过此 API 获取姿态信息,因此可能会像在 10.1.1 跨上下文识别用户 中提到的那样用此信息识别用户。 同样的缓解措施也适用。
通过 iframe,恶意行为者可以注入自己的代码来访问姿势信息,并可能利用这些信息来跟踪用户。
这种理论上的攻击可以通过10.2.1 数据最小化以及姿势值本身携带的价值信息很少且在很长一段时间内保持稳定这一事实来缓解。
API 暴露了称为 姿态 的高级抽象,它可以是
"continuous" 或
"folded"。
不支持不同姿态的设备默认为
"continuous"。
这意味着最多增加一位熵。最多是因为揭示这一位需要用户进行显著、明确的物理操作,以改变设备姿态并触发更改。
实现可以使用多种低级信息来确定最合适的高级姿态,但通过此 API 不会暴露任何低级细节。 此外,任何精细的低级传感器读数都不存在与高级姿态状态的一对一映射。 实现可以使用例如铰链角度传感器、其他传感器、键盘是否已对接或支架是否已展开等信息,或者这些信息的任意组合, 来确定给定外形的最合适姿态。 这种抽象确保只暴露实现预期功能所需的最少信息,从而遵循数据最小化原则。
只有对于每个 活跃 文档,其可见性 状态 为 "visible" 时,才会触发姿态值变更事件,如设备姿态变更步骤中所述,并且 在不满足该条件时轮询该值,将返回一个陈旧 值,因为该值仅在可见性状态为 "visible" 或刚刚变为 "visible" 时才会更新。
用户需要进行显著且明确的物理操作来修改设备姿态,以触发姿态更改。 显著,是因为操作必须跨过每个 姿态值表 定义的阈值; 明确,是因为底层操作系统会根据姿态变化做出相应的适应,符合用户对该操作结果的预期。
Window
的宽度和高度。
如果设备处于折叠状态,该
元素将跨折叠区域布局,从而导致较差的用户
体验。另一种做法是将该元素显示在折叠区域的上方
或下方。
posture 来设计: 可折叠设备的理念是
其
多功能性,以及用户能够按
自己认为合适的方式改变姿态。类似于方向,
重要的是不要总是替用户作选择,因为他们可能有
其他需求,而应允许他们选择更适合其需求的 UI。
理想情况下,最好使 UI 可配置。
Device Posture API 给测试作者带来了挑战,因为要全面 测试接口需要物理硬件设备。为了解决 这一挑战,本文档定义了 [WEBDRIVER2] 扩展命令,允许用户 控制所报告的设备姿态并 模拟真实设备。
为了支持下面的扩展命令及其与 8. 算法的集成,顶级 可遍历必须具有以下 内部槽:
| 内部插槽 | 描述 |
|---|---|
| [[PostureOverride]] |
覆盖硬件提供的当前姿态。
可能的值:
|
| HTTP 方法 | URI 模板 |
|---|---|
| POST | /session/{session id}/deviceposture |
此扩展命令将
设备姿态更改为特定的
DevicePostureType。
| 参数名称 | 值类型 | 必需 |
|---|---|---|
| posture | String | 是 |
远端 步骤为:
continuous" 也不是
"folded",则返回带有 WebDriver 错误代码 invalid
argument 的 error。
null 的success。
| HTTP 方法 | URI 模板 |
|---|---|
| DELETE | /session/{session id}/deviceposture |
此扩展命令会移除 设备姿态覆盖,并将 设备姿态控制权交还给硬件。
远端 步骤为:
null,则返回带有数据 null 的success。
null。
null 的success。
本节是非规范性的。
这是一个简单的用例,将 姿态 打印到控制台上。
navigator.devicePosture.addEventListener("change", () => {
console.log(`The current posture is: ${navigator.devicePosture.type}!`);
})
设备正在用于视频通话网络服务。它可以折叠成笔记本姿态,当放置在平面上时可以实现免提体验。 用户代理检测到姿态后,用户界面会得到增强。类似的示例可以为内容适应任意姿态而起草。 有关其他关键场景,请参见 explainer。
@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);
}
}
由于 device-posture 的有效值之一总是为真,您可以使用以下代码段来检测用户代理是否支持该媒体特性:
@media (device-posture) {
/* 浏览器支持 device-posture 特性 */
}
除了标记为非规范性的部分外,本规范中的所有编写指南、图表、示例和注释都是非规范性的。本规范中的其他内容均为规范性。
本文档中的关键词 MUST 和 SHOULD 应按 BCP 14 [RFC2119] [RFC8174] 中所述进行解读,且仅当它们如这里所示以全 大写形式出现时才如此。
本规范定义了一个产品的一致性标准: 一个实现其包含接口的用户代理。
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"
};
本节是非规范性的。
我们感谢 Diego González 作为创始编辑对 本规范做出的重大贡献,以及为本规范和设备与传感器工作组 创建视觉标识。
我们要衷心感谢 Daniel Appelquist、Jo Balletti、Michael Blix、Paul Grenier 和 Laura Morinigo 对本工作的贡献。
本节内容不具约束力。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: