过去这几年，前端圈其实把大量工程精力都消耗在了一件极其别扭的事情上：用动辄几十 KB 的 JavaScript 代码和复杂的受控状态机，去重新实现浏览器原本就该做好的交互。

最典型的例子就是弹窗、下拉菜单和手风琴。以前为了在页面上放一个带头像的下拉选择框，或者一个点击遮罩就能自动退出的浮层，我们往往得在项目里装上 Radix、Floating UI、Focus-trap 这些大大小小的第三方 NPM 包。组件代码里也塞满了一大堆 isOpen、useState、useEffect 和各种 click-outside 事件监听。要是碰上移动端软键盘突然弹起、深层 Shadow DOM 样式隔离，或者 z-index: 9999 层级踩踏，光是排查样式和焦点问题，少说也要折腾一两个小时。

最近这半年，主流浏览器内核其实都在加速推 Baseline 规范。因为很多原本非得装个第三方组件库才能勉强跑通的交互逻辑，如今直接在 HTML 标准底层就有现成的原生支持了。不过把这批新特性全部翻了一遍之后就会发现，这里面其实分为好几类：有些是能让我们明天就在生产环境里甩掉几万行胶水代码的减负利器，有些则依然停留在单家浏览器的实验阶段。今天我就把其中最核心的几项变化理一理，看看到底哪些可以果断上车，哪些必须果断劝退。

生产减负利器：干掉冗余的状态机与样式黑魔法

第一类特性是已经形成跨浏览器共识、或者主流实现已经落地的能力。它们针对的就是我们日常写得最多、也最容易出 bug 的场景。

声明式唤起：用 command 和 commandfor 彻底告别 onClick

以前不管用 React 还是 Vue，控制一个弹窗或者浮层的显示隐藏，标准动作都是在按钮上绑定点击事件，然后再去改一下某个响应式状态变量：

<!-- 过去的经典写法：必须依赖 JS 胶水代码 -->
<button onclick="setModalOpen(true)">打开面板</button>
<dialog id="user-dialog">
  <p>个人资料配置</p>
  <button onclick="setModalOpen(false)">关闭</button>
</dialog>

这种写法大家平时写习惯了，好像觉得理所当然。但如果一个页面里有几十个分散的抽屉、提示框和操作菜单，我们就得老老实实写上几十组开关函数与事件闭包。

现在 HTML 原生给出的解法是 command 和 commandfor。按钮只要自己声明要对哪个目标元素执行什么操作，浏览器原生底层就会自动派发命令，中间根本不需要哪怕一行 JavaScript 胶水代码：

<!-- 2026 原生解法：0 行 JS 驱动弹窗 -->
<button commandfor="user-dialog" command="show-modal">打开面板</button>

<dialog id="user-dialog">
  <p>个人资料配置</p>
  <button commandfor="user-dialog" command="request-close">关闭</button>
</dialog>

浏览器内部其实已经给内置好了一批高频动作。比如专门针对 <dialog> 的 show-modal、close、request-close，还有专门针对 Popover 浮层的 show-popover、hide-popover 和 toggle-popover。

要是业务里有一些特定的自定义控制需求，比如控制一个全局音频播放器，我们也可以直接使用 -- 开头的自定义命令标识：

<button commandfor="audio-player" command="--toggle-play">播放 / 暂停</button>

<audio id="audio-player" src="podcast.mp3"></audio>

<script>
  const player = document.querySelector("#audio-player");
  player.addEventListener("command", (event) => {
    if (event.command === "--toggle-play") {
      player.paused ? player.play() : player.pause();
    }
  });
</script>

这种机制直接把“按钮发出意图”和“目标处理逻辑”给拆开了。按钮本身只要把命令派发出去就行，完全不用关心目标组件内部到底是怎么跑的，而且也省得到处传回调函数的麻烦，代码写起来自然清爽得多。

可定制 select：甩掉几十 KB 的模拟下拉组件

长期以来，原生 <select> 标签都是很多前端开发者心里的一块病。只要产品经理提了一句“选项里能不能放个用户头像”，或者“选中以后能不能加个带颜色的状态标签”，原生的下拉框基本就当场歇菜了。过去为了搞定这类需求，大家只能咬着牙去装那些几十 KB 的模拟组件库，拿 div 和绝对定位一点一点去模拟一个下拉菜单。写完之后不仅要自己监听键盘上下键事件，还要提防父容器的 overflow: hidden 把弹出的菜单给硬生生切掉一截。

现在 Chrome 与 Safari 已经先后实装了基于 CSS 的原生可定制选择框。我们只需要在样式表里加上一行 appearance: base-select，就能把下拉菜单内部的结构控制权全部拿过来：

select,
::picker(select) {
  appearance: base-select;
}

在 HTML 模板里，我们就可以直接在 <option> 内部塞进头像、多行描述文本或者图标了，甚至还可以用 <selectedcontent> 标签来精确定义当前选中的内容模板：

<select>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option value="alice">
    <img src="/avatars/alice.png" alt="" width="20" height="20">
    <span>Alice (架构师)</span>
  </option>
  <option value="bob">
    <img src="/avatars/bob.png" alt="" width="20" height="20">
    <span>Bob (运维工程师)</span>
  </option>
</select>

通过配合 ::picker(select) 伪元素和 select::picker-icon 图标伪元素，以前必须靠几万行 JS 代码才能跑起来的富文本下拉框，现在直接用纯 HTML 和 CSS 就能轻松搞定了。而且这个下拉浮层是直接挂在浏览器的顶级层（Top Layer）上的，就算外层容器写了 overflow: hidden 或者奇怪的 z-index，它也完全不会被切掉，直接就浮在整个网页的最上面。

自动响应式图片：sizes="auto" 终结计算地狱

我们在页面上做图片加载优化的时候，经常会写 srcset 搭配 sizes 属性。但是真正手写过 sizes 的朋友都知道，那段媒体查询规则维护起来有多恶心：

<!-- 以前手写 sizes：既冗长又难维护 -->
<img 
  srcset="img-400.webp 400w, img-800.webp 800w, img-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  src="img-800.webp"
  alt="封面图"
>

只要设计师改了一下栅格断点或者卡片边距，这段写死在 HTML 里的 sizes 就会直接对不上。要是宽度算小了，图片在高分屏上就会发糊；要是宽度算大了，浏览器就会提前下载超出实际渲染尺寸两三倍的大图，白白浪费用户的流量。

现在只要搭配 loading="lazy" 懒加载，直接在图片上挂一个 sizes="auto" 就可以了：

<img 
  srcset="img-400.webp 400w, img-800.webp 800w, img-1200.webp 1200w"
  sizes="auto"
  loading="lazy"
  width="800"
  height="600"
  src="img-800.webp"
  alt="封面图"
>

浏览器会在这个图片真正滚进视口、而且算完了 CSS 布局之后，自动拿它在屏幕上实际占用的物理像素宽度，去 srcset 候选列表里匹配最合适的一张图。这样一来，不仅完全不需要人工再去推算复杂的媒体查询断点，而且主流浏览器目前已经全面支持了这个属性，直接扔进生产模板里用就行了。

为了让大家更直观地看清这些原生能力带来的变化，我把新旧解法的改造成本和收益整理成了下面这张对照表：

架构级解耦：解决微前端与组件库的陈年痛点

第二类特性主要面向需要维护大型复杂前端、设计系统以及微前端基建的团队。它们解决的是过去一直找不到优雅解法的深水区问题。

Scoped Element Registries：多版本 Web Components 并存

如果是在微前端或者大型 Monorepo 架构底下，我们经常会看到，一个页面往往是由好几个团队独立开发出来的子模块给拼在一起的。如果团队 A 的旧卡片组件基于设计系统 v2（在全局注册了 <user-card>），而团队 B 的新业务必须依赖设计系统 v3（里面同样包含一个 <user-card>），过去浏览器里的 customElements.define 就会当场抛出重名异常，整个子应用直接报错挂掉。

大家以前为了绕开这个冲突，要么强行要求业务团队在标签名后面加版本号后缀（比如改成 <user-card-v3>），要么就得在 Webpack 或者 Vite 构建阶段写很繁琐的 AST 插件去自动改名。

现在有了 Scoped Element Registries（独立元素注册表），每个组件实例就可以有自己专属的注册表对象了：

// 创建独立的自定义元素注册表
const customRegistry = new CustomElementRegistry();
customRegistry.define("user-card", UserCardV3);

// 将该注册表精确绑定到当前 Shadow DOM 作用域
const shadowRoot = hostElement.attachShadow({
  mode: "open",
  customElementRegistry: customRegistry
});

这样在同一个页面里，团队 A 可以继续在全局作用域跑旧版组件，团队 B 的组件则在自己的 Shadow Root 内部引用新版本类定义。两个团队用的标签名完全一样，但是彼此之间完全互不干扰，微前端多版本依赖冲突的老大难问题，总算有了官方层面的解法。

Reference Target：打通跨 Shadow DOM 的无障碍关联

另一个困扰前端组件化方案多年的难题是无障碍绑定。比如我们封装了一个自定义输入框组件 <fancy-input>，把真正的 <input> 节点藏在组件内部的 Shadow DOM 里面：

<label for="username">用户名</label>

<fancy-input id="username">
  <!-- 内部 Shadow DOM 里有真正的 input id="real-input" -->
</fancy-input>

在以前，外层的 <label for="username"> 根本没有办法把焦点传透到 Shadow DOM 里面的输入框，屏幕阅读器也识别不出来这两个东西之间的关联。原因其实很简单：DOM 的 ID 寻址被 Shadow DOM 的封装边界给直接拦住了。

现在借助 shadowrootreferencetarget 属性，组件开发者就可以在模板上明确指派内部的核心受众节点：

<label for="username">用户名</label>

<fancy-input id="username">
  <template shadowrootmode="open" shadowrootreferencetarget="real-input">
    <span class="prefix">Icon</span>
    <input id="real-input" type="text">
  </template>
</fancy-input>

这样外部的 <label for="username"> 被用户点击的时候，浏览器就会自动把聚焦和交互动作精准分发给内部指定的 real-input 元素，底层的无障碍可访问性树也会自动把标签和输入框连在一起。目前该特性在 Chrome 中已经正式实装，Safari 和 Firefox 也已经进入实验标记阶段，维护公司内部通用组件库的同学，完全可以提前做一些技术预研了。

清醒劝退：这些看起来很炫的特性，现在千万别当主力

在看到新技术快速推进的同时，作为踩过无数兼容性深坑的前端工程师，我们也必须保持清醒。有些新特性在官方演示里看起来特别美妙，但真要放进国内现有的业务生产环境里，现阶段还是得先留个心眼。

权限元素：别把核心架构押在单边试验上

Chromium 团队前段时间力推了一批专门用来处理浏览器权限的标签，比如 <geolocation> 和 <usermedia>。

官方给出的测试数据其实挺漂亮的：很多用户在第一次看到授权弹窗的时候，经常会下意识顺手点个“拒绝”，之后这个权限就被浏览器直接锁死了；以前大概只有 10% 的用户懂得自己去翻复杂的浏览器设置菜单找回权限，而如果用这种内置恢复流程的原生授权按钮，重新找回权限的成功率能直接跳到 65% 以上。

但是冷静下来看一看目前的浏览器生态就会发现，这套能力基本上还是 Chrome 一家在往前跑，Mozilla 和 WebKit 社区对此依然保留了相当大的分歧。更麻烦的是，国内很多移动端业务都跑在微信内置 Webview 或者各类定制壳浏览器里，这些特殊环境根本就不会去响应这些新标签的原生系统授权弹窗。

所以现阶段如果只是想稍微提升一下用户授权的成功率，我们可以把它当成渐进增强的一个锦上添花的小点缀。但在核心业务逻辑上，大家还是老老实实保留原本的 navigator.permissions 和 navigator.mediaDevices 降级兜底方案，千万别图省事把旧代码全给删了。

3D 标签 model：苹果生态的独角戏，标准未定别盲目上车

苹果在 WWDC26 上高调演示了原生的 <model> 标签，说是不用写任何 Three.js 或者 WebGL 代码，只要写一行 HTML 标签，就能在电商详情页里塞进一个可以用手指随意拖拽旋转、甚至带环境光照的 3D 模型：

<model src="product.usdz">
  <img src="fallback.jpg" alt="商品静态图">
</model>

这个效果在演示 Demo 里看起来确实很酷，但在真实项目里要是盲目上车，大概率会踩中深水坑。

最要命的问题还是格式生态。苹果在标签里强推的是它自己的 usdz 格式，而目前整个主流三维建模社区、游戏行业以及 Android 生态，大家通用的格式基本全都是 gltf 或者 glb。不仅文件格式严重割裂，W3C 规范草案里关于材质加载和通用数据交换的标准，各大厂商现在还在激烈拉扯。

除非我们现在做的就是一个专门跑在 Safari 或者苹果设备上的特定内嵌活动页，否则真要在跨平台业务里做 3D 商品展示或者复杂的三维交互，老老实实上 WebGL 或者 Three.js 才是最稳妥的。

适用边界与重构建议

从以前动不动就手写几十 KB 的状态管理胶水，到现在直接把顶层弹窗和焦点控制交还给浏览器，HTML 这一轮演进，算是真正在给前端工程师减负了。

不过这并不意味着我们明天一上班就得把手头的老项目全推翻重写。更稳妥的做法，还是按照场景分批推进：

比如对于新开发的管理后台或者独立工具页面，遇到模态框、消息浮层和抽屉，我们可以优先考虑用 <dialog> 加上 commandfor 来代替以前那套繁琐的 useState。这样不仅能从项目里直接删掉一堆三方库，而且像移动端软键盘把弹窗顶歪、或者浮层被遮罩挡住这些常年让人头疼的恶心 Bug，浏览器原生就顺手给解决了。

对于页面里的响应式大图，只要本来就配合了懒加载，直接把那一长串又臭又硬的媒体查询换成 sizes="auto" 就行了，改动成本非常小，后续维护起来也省心得多。

不过像权限按钮和 3D 模型这类目前各大浏览器还没吵明白的前沿特性，建议我们大家先抱个看热闹的心态关注着就好。把力气花在真正能产生确定性收益的地方，让浏览器去接管它原本就该做好的事情，我们自己也能早点下班，这才是技术演进该有的样子。平心而论，大家平时手写这些弹窗和下拉框的时候，被哪个老 Bug 坑得最惨啊？欢迎在评论区一起吐吐槽吧。

#HTML原生新特性 #前端架构 #CSSBaseSelect #CommandFor

阅读原文：点击这里​