一个 select 应该告诉你一些信息

# 一个 select 应该告诉你点什么 来源：https://alfy.blog/2026/10/27/a-select-should-tell-you-something.html **注意：**你的浏览器还不支持可自定义的 select，所以下面的"改造后"示例看起来就是普通的 select。你的访客在这个浏览器里看到的也正是这样。想看到区别，请用 Chrome 或 Edge 打开本页。 关于 `appearance: base-select` 以及如何使用它的文章已经不少了。我们终于可以给 select 加样式了。但更大的变化在于 option 能承载什么。直到现在，一个 option 只是一行纯文本，于是一个人做决定所需要的一切，要么硬塞进标签里，要么干脆舍弃。现在一个 option 可以承载人们真正用来决策的东西：预览、数字、职位、警示。人们不再逐行阅读、绞尽脑汁，而是开始"一眼认出"。 下面有五个 select，每个都展示了改造前和改造后。改造前是如今大多数表单的样子。改造后是同一个 `select`，键盘行为相同，表单值相同，只是展示的内容变了。 如果你想了解实现机制，Chrome 团队的公告（https://developer.chrome.com/blog/a-customizable-select）和 MDN 的指南（https://developer.mozilla.org/docs/Learn_web_development/Extensions/Forms/Customizable_select）讲得很清楚。 ### 眼见为实，别靠想象 字体选择器通常只列名字。要选得好，你要么本来就记得 Fraunces 长什么样，要么先选它、看看效果，再回来试下一个。当每个 option 都用自己的字体来渲染时，option 本身就是预览。你评判的是字形，而不是名字。 改造前：标题字体 改造后：标题字体 改造前，你得知道 Fraunces 长什么样。改造后，你直接看到。 这个模式并不新鲜。我们早就在文档编辑器（如 Google Docs）和设计工具（如 Figma、Photoshop）里见过它了。它现在也轮到我们用了，而且只需要给每个 option 加一条行内样式，`style="font-family: 'Fraunces', serif"`，收起状态的控件在你选择之后也会保持该字体。 我们还可以展示每种字体的类别，比如衬线（Serif）、无衬线（Sans）、等宽（Mono）、展示体（Display）或手写体（Handwriting）。 ### 让列表替你算数 时区选择器通常长得像"（GMT+09:00）东京"。这个偏移量很精确，但几乎从来不是你真正想知道的。你想要的是那边现在几点，于是你得在脑子里把自己的时间和偏移量相加，午夜前后还容易算错。把每个城市的当前时间以及白天还是黑夜显示出来，问题在你选择之前就自己回答了。 改造前：在…安排会议 改造后：在…安排会议 改造前，你得根据偏移量自己推算时间。改造后，列表直接告诉你，还告诉你那边是白天还是黑夜。 这是唯一需要 JavaScript 的示例，因为时间来自 `Intl.DateTimeFormat`。 ### 一目了然地比较 配送选项通常是一组单选按钮，每个选项的详情都写成一句话。公平地说，单选按钮有其真正的优势：不用点击就能看到所有选项，对于两三个简短的选择，它就是正确的模式。但一旦每个选项带了几条信息，这些信息就会散落成一段段文字。比较就意味着读完每句话，还得在脑子里记着那些数字。 把信息放进对齐的列里，比较就变成了顺着一列往下扫一眼，而且只占用一个字段的空间。 改造前： 改造后：配送方式 改造前，详情藏在句子里，占满了整个面板。改造后，同样的选择装进一个字段里，到达时间和价格整齐对齐。 这些列就是每个 option 上的网格： ```css option { display: grid; grid-template-columns: 1fr 6.5rem 4rem; } ``` ### 把人区分开 在一家大约两百人的公司里，我们有两位同名同事，分属不同部门。每次我需要选其中一位，我都靠职位来分辨。照片的作用比你想的小，因为人们常常不知道同事长什么样，尤其是另一个部门的。纯文本的 select 只会给你两个一模一样的选项，全靠猜。把职位和部门放在名字下面，它们就变成了两个不同的答案。收起状态的控件也会保留职位，所以任何审阅表单的人都能看出你选的是谁。 改造前：把发票发给 改造后：把发票发给 两个人同名。改造前，你只能猜。改造后，职位和部门让它们成为两个不同的答案，列表收起后也一样。 ### 选择之前先知晓 有些选项带有后果。在普通 select 里，你是事后才知道的。在列表里把这些选项标记出来，你在选择的同时就知道了。 改造前：与…共享报告 改造后：与…共享报告 改造前，你共享之后才发现某个团队需要审批。改造后，你在选择的时候就知道了。 徽章只出现在需要特别注意的选项上，其他地方一概没有。 ### 它仍然是一个 select 本文中每一个"改造后"都是一个普通的 `select`。键盘处理、首字母跳转、表单提交、`select.value`、`required`、校验以及无障碍角色全部由浏览器负责，控件本身不需要任何 JavaScript。 更大的取舍在于手机上。原生 select 会打开操作系统自带的选择器：iOS 上是滚轮，Android 上是底部面板。这些大家都熟悉，为拇指操作而设计，也针对各平台的无障碍特性做了调校。可自定义的 select 不会用它们，而是自己在页面上绘制列表。 你不必为所有人选择同一种行为。只在有鼠标或触控板的环境下启用，触摸设备保留原生选择器： ```css @media (hover: hover) and (pointer: fine) { select, ::picker(select) { appearance: base-select; } } /* 或者我们可以根据窗口大小判断 */ @media (min-width: 768px) { select, ::picker(select) { appearance: base-select; } } ``` 手机用户看到的是每个选项的纯文本，没有额外内容——这也是为什么文本必须能够独立成立的又一个理由。本文中的示例在所有环境都启用了自定义，所以你可以在任何设备上尝试。 ### 今天就开始用 可自定义的 select 是教科书式的渐进增强。不支持它的浏览器不会出错，只是显示普通的原生 select，只保留每个选项的文本，并提交相同的值。没有人会因此得到比现在更差的表单。 如果你写这篇文章时正在用 Firefox 阅读，上面那些"改造后"示例就是你的访客会看到的样子。 于是只剩下一条要求，而这本来就是好实践：每个选项的文本必须能够独立成立。应该是"Ahmed Mostafa，会计 · 财务部"，而不只是一个名字；应该是"Express，明天，$8.50"，而不是三个零散的片段。在示例中，一些小的分隔符 span 在自定义版本里被隐藏，在普通版本里则让整段文字读起来像一个句子。 不需要 polyfill。 所以没有理由再等了。找到你的产品中最让人犹豫不决的那个 select，问清楚人们真正想了解的是什么，然后把答案放进 option 里。其余的，统统省掉。