前端开发人员和 Web 设计师生活在一个疯狂的多设备现实中。
几个月前,Red Hat UXD 团队 讨论了如何为移动环境设计企业应用程序。 我的才华横溢的同事 Sarah 和 Jenn 指出,触摸设备不应该只根据尺寸来判断。
假设是令人着迷的。 如果我们能够在某些边界上达成一致,那么 Web 设计是否会更容易控制呢? ” - Jeremy Keith,弹性 Web 设计
如今,在交互设计和前端开发的复杂世界中,出现了一个新的复杂层。
硬件行业已经创造了巨大的触摸屏电视、超大平板电脑(如 iPad Pro)甚至巨大的触摸式台式电脑(如全新的 Surface Studio)。 这意味着我们不能再假设一个小视窗是触摸屏,而一个大视窗不是。 有时大屏幕是触摸屏,要求用户使用手指,而小屏幕有触控笔。
响应式视窗媒体查询很棒,但还不够。
我们可以使用像 Modernizr 这样的 JS 工具检测触摸屏,但 CSS 拥有一个更智能、更灵活的隐藏宝石。
交互式媒体功能
感谢 W3C CSS 工作组 和 CSS 社区,我们有了一个更清洁的解决方案。
在 媒体查询级别 4 工作草案 中,有一个关于 交互式媒体功能 的规范,其中包括三个定义
这些提供了根据用户指向设备的存在和准确性以及它是否具有悬停元素的能力查询文档的能力。
让我们仔细看看每一个
指向设备质量:指针功能
指针媒体功能用于查询指向设备(如鼠标)的存在和准确性。 如果设备具有多种输入机制,则指针媒体功能必须反映“主要”输入机制的特征,如用户代理所确定。 ” - W3C
这里的关键是指向设备的“准确性”。
- 鼠标或绘图触控笔非常精确,定义了
fine
的值。 - 手指或 Kinect 外设则不是,并取
coarse
的值。
因此,我们可以根据用户的指针功能调整我们的 UI 元素。 这对于在用户的主要输入机制是手指时,使命中区域更大非常有用。
/* The primary input mechanism of the device includes a pointing device of limited accuracy. */
@media (pointer: coarse) { ... }
/* The primary input mechanism of the device includes an accurate pointing device. */
@media (pointer: fine) { ... }
/* The primary input mechanism of the device does not include a pointing device. */
@media (pointer: none) { ... }
此查询的一个示例用例是调整复选框或单选按钮的点击区域大小。
悬停功能:悬停功能
悬停媒体功能用于查询用户在页面上悬停元素的能力。 如果设备具有多种输入机制,则悬停媒体功能必须反映“主要”输入机制的特征,如用户代理所确定。 ” - W3C
重要的是要注意,它只评估主要输入机制。 如果主要输入机制无法悬停,但辅助输入可以,那么查询将解析为 none
例如,触摸屏,其中长按被视为悬停将匹配 hover: none”。 - W3C
- 触摸屏设备,其中主要指针系统是手指,无法悬停,将取
none
的值。 - 主要输入是鼠标且可以轻松悬停页面部分的设备将取
hover
的值。
/* Primary input mechanism system can
hover over elements with ease */
@media (hover: hover) { ... }
/* Primary input mechanism cannot hover
at all or cannot conveniently hover
(e.g., many mobile devices emulate hovering
when the user performs an inconvenient long tap),
or there is no primary pointing input mechanism */
@media (hover: none) { ... }
此查询的一个很好的用途是下拉菜单。
罕见的交互功能:any-pointer 和 any-hover 功能
在既有触摸屏又有鼠标或触控笔的设备上,例如 Microsoft Surface,hover
和 pointer
媒体查询将只评估主要输入机制。
正如 Andrea Giammarc 所指出的,他的 Dell XPS 13 英寸触摸屏取 fine
的值,即使它确实有触摸屏,因为主要输入机制是鼠标。
@Real_CSS_Tricks 顺便说一句,我的触摸屏和那个方法在 Chrome 中完全失败了。 😕
— Andrea Giammarchi (@WebReflection) 2017 年 2 月 5 日
如果我们想要这样的设备取 coarse
或 hover
的值,我们可以使用罕见的交互功能。
any-pointer 和 any-hover 媒体功能与 pointer 和 hover 媒体功能相同,但它们对应于用户可用的所有指向设备的联合功能。 如果不同的指向设备具有不同的特征,则可以匹配多个值。 它们必须只匹配 none,如果所有指向设备都将针对相应查询匹配 none,或者根本没有指向设备。 ” - W3C
/* One or more available input mechanism(s)
can hover over elements with ease */
@media (any-hover: hover) { ... }
/* One or more available input mechanism(s) can hover,
but not easily (e.g., many mobile devices emulate
hovering when the user performs a long tap) */
@media (any-hover: on-demand) { ... }
/* One or more available input mechanism(s) cannot
hover (or there are no pointing input mechanisms) */
@media (any-hover: none) { ... }
/* At least one input mechanism of the device
includes a pointing device of limited accuracy. */
@media (any-pointer: coarse) { ... }
/* At least one input mechanism of the device
includes an accurate pointing device. */
@media (any-pointer: fine) { ... }
/* The device does not include any pointing device. */
@media (any-pointer: none) { ... }
设备示例
匹配指向和悬停组合的典型设备示例
pointer: coarse |
pointer: fine |
|
---|---|---|
hover: none |
智能手机、触摸屏 | 触控笔式屏幕(Cintiq、Wacom 等) |
hover: hover |
任天堂 Wii 手柄、Kinect | 鼠标、触摸板 |
Patrick H. Lauke 已经编写了关于每种设备类型如何评估交互式媒体查询的 很棒的指南。
这真的很酷,对吧? 我听到你在喊:浏览器支持怎么样?
浏览器支持一点也不差!
即使这只是一个工作草案,它也具有 相当不错的支持。
我的简单测试 在 Chrome、Chrome for Android、Safari、Edge、Opera、三星浏览器和 Android 浏览器上成功,但它在 FireFox、Opera Mini 或 IE 上不起作用。
查看 Pen 触摸屏测试,作者是 Andres Galante (@andresgalante),发布在 CodePen 上。
FireFox 和 IE 只占移动/平板浏览器市场份额的 2% 多一点。 我找不到有关触摸电视或其他不是移动设备或平板电脑的触摸屏设备的信息。
我认为我们已经准备好使用此功能,并且随着 FireFox 添加对它的支持,并且 IE 彻底消失,我们将获得全面支持。
“卡片选择”用例
一个月前,我们着手为新版本的 PatternFly 实现一个 多选卡片组件,这是一个我为之做出贡献的开源设计系统。 这是使用 hover 和 pointer 媒体查询的完美案例。
要选择卡片,当用户将鼠标悬停在上面时,会显示一个复选框。 如果用户无法将鼠标悬停在元素上,那么我们始终显示复选框。
为了改善这种交互,如果主要输入机制是粗略的,我们增加了复选框的命中区域。
查看 Pen 多选卡片,作者是 Andres Galante (@andresgalante),发布在 CodePen 上。
Firefox 和 IE 将始终显示默认复选框。
尺寸并非决定一切
设备应该根据其功能来评判,因为最终,正是这些功能定义了它们。
这是一个鲜为人知的特性,它打开了通往令人兴奋的新挑战的大门。我迫不及待地想知道我们作为社区能用它做什么。
参考资料
代码中所有注释的描述都来自Mozilla 开发者网络。
好文章。感谢分享这个属性。我不知道它存在。
我的第一个想法是,它似乎为细微的原因增加了不必要的复杂性。我们不能只针对触控进行设计,这样就可以用一套规则覆盖所有人吗?我无法想象鼠标用户会抱怨一些额外的填充或更大的目标。它实际上可能有助于 50 岁以上群体用户的可用性,他们有较弱的运动控制,可以从更大的目标中受益。我对这个想法天真了吗?
我还要争论说,专门为鼠标输入编写代码并不利于未来的发展。一旦增强现实完全普及,我无法想象传统的桌面设置将如何继续存在。它已经被移动设备吞噬。专注于触控的界面似乎是未来。我们应该专注于此。您的想法呢?
很棒的文章。我立即找到了一个用例,我们需要链接在幻灯片库中左右移动,以便在非触控设备上使用鼠标点击,而在所有支持触控的设备上使用滑动手势。
Brian,虽然我认为鼠标或键盘不会很快消失,但我完全同意我们应该创建更大的点击区域,并且总的来说,我们应该避免任何媒体查询并设计灵活的 UI。
对我来说,交互式媒体查询最有趣的部分是能够知道用户是否可以悬停,尤其是当组件依赖于悬停交互时。
鉴于此,似乎首先设计“非悬停粗略”将成为一个伟大的可用性和可访问性默认值,然后设计师可以针对那些“精细”和“基于悬停”的场景进行扩展。
W3C 有关这种方法的任何指南吗?
非常有用的文章,但您可能需要考虑编辑开头附近的这段代码
这是不正确的,并且Modernizr 的文档强调了这一点
抱歉听起来如此挑剔,我确实认为这是一篇非常实用的文章,并期待使用这些功能 :^D
不错的文章,但它似乎并不总是有效,因为它在我的华为智能手机上使用鼠标时检测到了我的手指。Android 4.4.4,Chrome 55