摘要

  • W3C 2018 年 2 月的 Selectors Level 4 草案把“元素已经获得焦点”与“浏览器认为应当看见焦点”分开；后者由 :focus-visible 表达。
  • 后续草案细化了判断线索：键盘导航、文字输入、读者的显示偏好，以及脚本把焦点从一个控件移到另一个控件时的连续性。浏览器掌握来路，网站设计标记。

设计师用鼠标点了页面上的按钮。按钮周围冒出浏览器自带的轮廓，跟精心挑选的配色不太合拍。他顺手写下 CSS，把轮廓清掉。鼠标测试一切正常。下一位读者按 Tab 键走进页面，焦点已经落到按钮上，眼睛却找不到地址。下一次回车会做什么，只好碰运气。那圈边框因为“太显眼”被辞退，而显眼恰恰是它的岗位职责。

W3C 2018 年 2 月 2 日草案拆开了两件常被一锅端的事。:focus 表示哪个元素当前接收输入；:focus-visible 表示浏览器判断这个焦点需要被看见。草案举了两个好懂的例子：文字框获得焦点后会接收键入内容，因此要提醒读者；用键盘切换到按钮时，读者也要知道 Tab 刚把自己送到哪里。鼠标直接点按钮，指针本身已替这次抵达提供线索。同一枚按钮，来路不同。

浏览器比网站更清楚这条来路。它看见键盘、指针和读者的设置；网站更清楚自己的颜色、线条和视觉节奏。若用 :focus 一刀切地扫掉轮廓，浏览器拥有的信息到了页面却无处呈现。给 :focus-visible 画一枚醒目的新轮廓，既能保住设计风格，也能让读者知道下一键将作用于谁。焦点框不必穿出厂制服，但也不能旷工。

2018 年 11 月 21 日草案给了一个毫不害羞的示例：符合 :focus-visible 的元素套上粗黄线，链接还多一层黄色背景。这不是设计师向默认样式投降，而是亲手把路标画得更清楚。页面上有十几个按钮和链接时，一条明亮的线比“你自己应该记得刚才按到哪儿了”可靠得多。

那份草案还列出了浏览器可参考的情形。读者若在系统或浏览器设置里要求始终看见焦点，选择已经非常明白。文字输入框会接收键入内容，值得显示位置。键盘或其他非指针设备带来的移动，通常也需要视觉提示；鼠标点击按钮时，点击动作本身给了另一种位置线索。草案把这些写成建议，让浏览器结合环境和偏好作决定，页面用选择器接住结果。

真正考验“记得来路”的场景发生在脚本搬动焦点时。读者用键盘打开一个弹出面板，程序马上把焦点放到面板里的第一枚按钮。11 月草案建议：若上一处焦点带着可见标记，新按钮也应接过它。否则读者刚跨过门槛，就把自己的位置丢了。指针开始的路径也有相应的连续处理。浏览器跟踪的是一次阅读行动，不是每个按钮孤零零的一次抽签。

到了 2022 年 5 月 7 日草案，这个分工写得更加利落：:focus 持续匹配当前焦点；浏览器决定要提示焦点时，:focus-visible 匹配它。网站可以改变标记的外观，而不必自己改写标记出现的时机。草案还建议浏览器的默认焦点样式也使用 :focus-visible。于是网站的新黄线与浏览器原有的提示可以依照同一套时机工作，不用在按钮边缘争抢话语权。

2022 年 11 月 11 日草案沿用这套机制；W3C 发布记录把 2018 年到 2022 年的修订排在一张时间表上。一个很小的 CSS 选择器，处理的是页面里很大的尴尬：人已经走到下一枚控件，页面却拒绝告诉他站在哪里。设计师可以让鼠标点击保持清爽，让键盘导航时的标记像路灯一样亮。

焦点框卷土重来，理由简单得不能再简单：读者想知道自己在哪儿。