余时行前两天在技术群里看到有人问：“各位，HTML6到底什么时候发布？听说新的Web环境里标签都不够用了，是不是该出HTML6了？”群里瞬间热闹起来，有人说是2025年，有人说根本不会有，还有人拿“CSS4”出来反将一军。我看得哭笑不得——这两个问题本质上是同一件事：HTML和CSS早就把“大版本升级”这条路径亲手砍断了，所有人在等一个永远不会来的马车，而身边的火车已经开出很远了。
这篇文章不打算给一个“因为没有所以没有”的敷衍答案。我想把HTML与CSS标准演进的历史脉络、组织逻辑、对开发者日常工作的实际影响一次说清楚。无论你是写业务代码的前端，还是偶尔碰HTML、CSS的后端或全栈，甚至是刚入行的小白，读完后你应该都能明白：为什么今天的新特性不是靠版本号告诉你，而是靠浏览器发布日志告诉你。
1. 版本号先把自己玩砸了：HTML4到XHTML2的弯路
要理解为什么没有HTML6，得先回到HTML还严格使用版本号的年代，看看那条路为什么走不通。
早期的HTML版本迭代其实非常“版本号驱动”。HTML 2.0在1995年以RFC文件形式发布，1997年HTML 3.2上场，紧接着是1997年底的HTML 4.0，再到1999年的HTML 4.01。这段时间里，浏览器厂商和W3C都默认一种工作方式：大家先坐在一起讨论一个完整的新版本，定稿后发布，然后浏览器再花好几年去实现。这种模式在Web还很年轻、功能相对简单的时候勉强能运转。
问题出在XHTML身上。2000年，W3C发布了XHTML 1.0，这是一份把HTML4重新用XML语法包装一遍的规范。它的核心思路很明确：让网页结构像XML那样严格规范，理论上可以跟其他XML工具链打通。如果仅止于此，XHTML 1.0其实还算一次温和的过渡。但W3C紧接着推行的XHTML 2.0，才是真正的分水岭。
XHTML 2.0的问题不是不好，而是太超前了。它计划抛弃HTML4里许多元素，引入一套全新的、更“合理”的结构体系。这在纸面上非常诱人，但有一个致命伤：完全不向后兼容。你可以想象一下，如果今天所有网站都不能在下一个浏览器版本运行，整个行业会陷入什么状态。浏览器厂商最不想看到的就是这种结果，所以没有任何一家愿意认真实现XHTML 2.0。
1.1 浏览器厂商的反抗与WHATWG的成立
2004年前后，W3C内部关于Web应用方向的争论已经到了白热化程度。苹果、Mozilla、Opera等浏览器厂商意识到，继续在W3C等一份完美的大版本规范，Web会错过整个应用化浪潮。于是他们另起炉灶，成立了WHATWG（Web Hypertext Application Technology Working Group），目标非常朴素：不再追求一个大而全、一次性定稿的HTML新版本，而是持续演进一套以实际浏览器反馈为驱动的规范。
WHATWG最初提的方案叫“Web Applications 1.0”，后来跟W3C在2007年合作，把它变成了我们熟悉的HTML5规范的起点。但这里有个关键点：HTML5从一开始就是按照“不断修订的Living Standard”方式来运作的，只是当时为了跟W3C合作，才被包装成一个“版本号”。这也是后来很多误解的根源——很多人都以为HTML5是一份像HTML4.01那样封存在时间线上的规范，但它从来不是。
1.2 HTML5“发布”后，版本号已经失去意义
2014年10月，W3C正式发布HTML5推荐标准。各大新闻标题都在喊“HTML5终于来了”，但实际Web开发者手里的HTML5早在好多年前就已经通过浏览器逐步可用。换句话说，标准的定稿只是一个仪式，浏览器早就实现了。
更值得注意的是HTML5发布之后的操作。W3C在2016年发布了HTML 5.1，2017年发布了HTML 5.2。但到了HTML 5.2之后，W3C正式终止了给HTML发布带编号的快照版本。原因倒也不复杂：每发一个新版本，都要把WHATWG的那个持续演进的规范重新快照一次，文档工作组消耗的时间成本巨大，而对浏览器厂商和开发者的实际指导意义非常有限。当规范本身已经细化到“某属性在某种场景下的算法步骤”时，“大版本号”这个东西就只剩下宣传意义了。
我自己的体会是：HTML版本号最后一次对开发有实际意义，大约是在“HTML5 vs HTML4”比较的时期——因为它代表了语义化标签、音视频支持、canvas这类划时代能力。但再往后，当你在Chrome里用了一个新的HTML特性，你去看文档，它永远标注的是“Living Standard中的某段”，而不是“HTML6新增”。这其实是好事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 2019年的关键握手：W3C把HTML的“方向盘”交给了谁
如果你观察Web标准新闻，会发现2019年有一个看起来不那么起眼但意义深远的节点：W3C与WHATWG正式签署合作协议，明确了HTML和DOM规范以WHATWG维护的Living Standard为准。W3C不再发布HTML/DOM的独立快照版本。
这次握手意味着什么？简单说，HTML和DOM的未来方向，正式从“委员会定稿制”切换为“浏览器实现驱动、持续修订制”。W3C当然没有缺席，它仍然会组织会员参与评审、反馈意见，并接手维护与无障碍、地理位置等相关的规范，但HTML这个大方向不再需要全体投票通过一个版本。
2.1 Living Standard具体是怎么“活”的
很多人可能不理解Living Standard的运作方式。它不是文件存在某个地方几年才动一次，而是像开源代码仓库一样持续提交更新。今天你查HTML规范里的某一段，可能跟三个月后看到的不一样。规范的每一次调整，背后都有对应的浏览器行为变化、开发者反馈或安全补丁需求。
一个很典型的例子就是<dialog>元素。它早在HTML5时代就被提出来，但标准里的行为细节经历了非常多轮修改，浏览器也在不同时期有不同的行为实现，直到前几年才趋于稳定并成为所有现代浏览器默认支持的特性。如果按大版本的思路，<dialog>可能会因为在HTML5阶段不够成熟而被塞进“HTML6”里，大家只能干等。但在Living Standard机制下，它可以在标准文本里一点点成熟，浏览器也可以逐个实现，谁都不用等谁。
再比如近几年非常受关注的popover属性，就是直接在Living Standard中一步步从实验性API演进成基线特性的。它的整个生命周期内根本不存在“HTML6先行版”这种东西——它就是把规范文本、浏览器实现和开发者测试反馈同时滚动推进。
2.2 一次真实感受：查HTML新特性比想象中简单
我经常被问到：“你怎么知道某个新HTML标签什么时候能用？”我的方法其实很土：先去MDN看浏览器兼容性表格，再去看对应的规范文本状态。Living Standard的规范页面虽然看起来复杂，但顶部会标注每个特性的状态，然后浏览器会实现。如果你看到一个特性已经在最新版Chrome、Safari、Firefox里都能跑，那就放心用。
记住一个核心判断标准：**对于HTML来说，将来不再有“版本号”来决定你能不能用一个新特性。能不能用，只取决于浏览器是否已经稳定实现它。**这跟前端框架“升级大版本后一起迁移”的逻辑截然不同。刚开始可能不习惯，但用熟悉后你会觉得这才符合Web平台演进的本来面貌。
3. CSS3本身就是“一堆规范”，所以CSS4根本装不到一个盒子里
聊完HTML，再来看CSS的演进。如果HTML这边的问题是版本号停止更新，那CSS这边的情况更有意思：**官方从来就没有打算发布一个叫做CSS4的整体规范。**你之所以会觉得应该有个CSS4，是因为CSS3的命名方式给所有人制造了错觉。
3.1 CSS2.1是一整本书，CSS3却是一套丛书
CSS 1诞生于1996年，CSS 2在1998年发布，但CSS2真正完整地定稿其实拖了很多年，因为语法描述中有很多细节在标注阶段才发现无法实现，最终大家熟悉的CSS 2.1在2011年才成为W3C推荐标准。CSS2.1是一份“整本书”性质的规范，把选择器、盒模型、布局、字体、颜色等所有内容全部写在一个文档里。
如果继续按这个方式迭代到CSS3，且不说文档体积会有多大，光让所有新特性一起定稿就是不可能完成的任务。比如Flexbox和CSS Grid虽然都是布局相关内容，但它们的复杂度差异非常大，开发进度完全不在一个节奏上。如果有一个“CSS3整体规范”要等所有模块都Ready才能推出，那Flexbox可能到今天都还在草案阶段。
所以W3C从CSS3时代开始就明确走向了“模块化”路线。CSS不再是单一规范，而是由一大批独立模块组成。每个模块叫“CSS 某个主题 Module Level 几”。比如：
- CSS Color Module Level 3
- CSS Selectors Level 3
- CSS Backgrounds and Borders Level 3
- CSS Flexible Box Layout Module Level 1
- CSS Grid Layout Module Level 1
其中有些模块从Level 3起步，有些则从Level 1起步，完全取决于历史渊源。
3.2 你以为的CSS4，其实早就在各个模块里Level 4了
那CSS4去哪了？我的回答是：它从来没被定义成一个东西，但你已经在用一部分了。举个很直观的例子：
Selectors Level 4现在就存在于W3C工作区中，它里面包含大量新选择器。还有CSS Color Module Level 4，它引入了广色域颜色、新的颜色函数，包括现在已经普及的oklch()。而CSS Grid Layout Module Level 2则带来了subgrid能力。这些模块各自的Level都大于3，所以如果把它们全部攒起来，确实可以戏称“这就是CSS4”。
但重点在于：官方不会把它们打成一个“总版本号”。因为一旦打成CSS4，就意味着浏览器要等所有模块定稿并通过测试后才能统一发布，这又回到了老版本的死路。CSS工作组的决定非常务实：让每个模块独立、随时可以升级，浏览器逐个实现，功能正常后直接上线。
3.3 为什么大家仍然习惯追问“CSS4什么时候出”
这里有个挺有趣的现象。社区里每隔一段时间就会有人问“CSS4”，很多内容网站甚至为了SEO专门做了“CSS4新特性”这种文章。这说明版本号对开发者来说不仅仅是技术标记，更是一种心理锚点——消息“CSS3出来了”，大家就知道可以用圆角、阴影和动画了；那“CSS4出来了”，是不是代表有一大波更牛能力要集中爆发？
但现实是反转的。对新特性影响最大的其实不是版本号，而是浏览器发布节奏。以CSS Nesting为例，这是一个让无数开发者等了很久的功能，可以把Sass风格的嵌套写法直接用在原生CSS里。它属于CSS Nesting Module，浏览器从2022年开始铺垫，到2023年已经在Chrome、Safari、Firefox主流版本中稳定支持。你根本不需要等“CSS4”，你只需要2023年某个浏览器自动更新到新版本，功能就解锁了。
所以当我想跟别人讲清楚这件事时，一般会用一个比喻：CSS2.1是一本合订本杂志，每一期要等所有文章都写完才能出版；CSS3之后的每个模块则像微信公众号，写一篇发一篇，你不用等一整期，每篇文章自己独立更新。
4. 没有“CSS4”不代表没有重磅更新：这几年上车的都是“模块级”大改
光说架构逻辑可能有点抽象。我挑几个最近几年你大概率已经接触过的模块级重大更新，让你直观感受“无版本号时代”到底在发生什么。
4.1 CSS Color Module Level 4：颜色体系的一次底层重构
如果你是老前端，对颜色值的认知可能还停留在#fff、rgb()、hsl()这种阶段。但CSS Color Level 4已经在底层重构了一遍颜色系统，带来了两个非常大的变化。
第一是支持广色域空间。原来的sRGB颜色范围有限，现在的display-p3可以表现更鲜艳的颜色。第二是引入了更科学的颜色函数，尤其oklch()和oklab()——它们是基于人类视觉感知均匀性设计的颜色空间，调整亮度、饱和度、色相时感觉非常直观。
我印象最深的一个例子是给项目做暗黑模式调色。以前用HSL手动调，很难保证不同颜色看起来亮度一致。换成oklch()后，把L通道固定住，换H和C的值，出来的多个色块在人眼中的明暗感受基本一致，整个调色效率高了很多。这种能力如果你要等“总版本号”发布，估计得等好几年，但现在直接用就行。
4.2 CSS Nesting：让原生CSS长出“嵌套能力”
CSS Nesting是这几年呼声极高的模块之一。它把你原本在预处理器里才能用的嵌套写法搬到了原生CSS中：
css复制.card {
background: white;
.title {
font-size: 1.5rem;
}
&:hover {
border-color: blue;
}
}
在浏览器支持之前，这类写法只能通过Sass或Less编译。而有了原生CSS Nesting后，项目可以少一层构建依赖，至少在处理简单样式时能省掉很多编译心智负担。
不过这里有个实战提醒：原生嵌套的解析规则跟Sass并非完全相同。比如嵌套选择器必须以符号开始等等，有一些细小的语法限制。如果你想直接迁移旧项目里的大量嵌套代码，建议先在浏览器控制台和文档里确认语法差异。总体而言，这个模块的意义不只是省事，更说明规范演化已经进入了“长在浏览器里按需迭代”的阶段。
4.3 Container Queries与@supports：特性时代的基本功
容器查询（Container Queries）是响应式设计领域近年来的重要突破。以前做响应式布局，只能监听视口宽度变化，但现在可以监听某个容器父元素的尺寸。这在大组件复用的场景中非常实用，比如一个“产品卡片”，在侧边栏里和在主内容区里宽度完全不同的情况，以前要靠各种覆盖类名处理，使用容器查询后直接根据容器宽度变样式。
css复制.product-card {
container-type: inline-size;
}
@container (max-width: 400px) {
.product-card {
display: grid;
grid-template-columns: 1fr;
}
}
这些能力完全不需要关心“CSS哪一版”，你需要的只是查询浏览器的支持范围，然后逐步使用。
5. 开发者的正确打法：特性检测、Baseline和新特性追踪指南
既然不再有大版本号，我们的工作判断也必须跟着变。过去你可能会在心里盘算：“等HTML6出来我再用<dialog>。”而现在正确的思路是：“查一下这个特性当前在目标浏览器里可不可用，如果可用就直接用，不可用则考虑是否做降级。”
5.1 用特性检测代替版本判断
遇到新属性或新API，最稳妥的做法就是使用特性检测。CSS里用@supports，JavaScript里用CSS.supports()。例如，当你考虑是否可以使用oklch()颜色作为按钮主色时，可以直接这样写：
css复制@supports (color: oklch(70% 0.15 25)) {
.primary-btn {
background-color: oklch(70% 0.15 25);
}
}
@supports not (color: oklch(70% 0.15 25)) {
.primary-btn {
background-color: #1a73e8;
}
}
JavaScript侧：
js复制if (CSS.supports('color', 'oklch(70% 0.15 25)')) {
console.log('可以安全使用 oklch');
}
要检测某个元素或API是否存在，也可以直接判断：
js复制if (typeof HTMLDialogElement !== 'undefined') {
// 使用 dialog.showModal()
}
这样你在代码层面就根本不关心浏览器叫什么版本，只要真机上跑一下就知道当前环境是否支持。这是无版本化时代的第一原则。
5.2 学会使用Baseline而不是只看某个浏览器的版本号
从前年开始，“Baseline”这个概念在Web社区里越来越常见。它是WebDX社区组推动的一套浏览器兼容性标注方案，试图统一Chromium系、Safari和Firefox对新特性的支持状态。当某一特性被三大浏览器核心都稳定支持后，它会被标为“Baseline Newly Available”，也就是可以放心使用。再经过约两年半的时间，会升级为“Baseline Widely Available”，适合作为默认能力使用。
我这两年给团队做技术选型时已经不太爱说“Chrome 120+和Safari 17+支持它”，感觉太绕。直接用Baseline状态去沟通，大家会很清楚：这个事情是新进基线还是已经很普及。MDN的兼容性表格中现在也在逐步以Baseline状态取代混乱的彩色表格，这对开发者做决策真的方便不少。
5.3 新特性追踪机制：从“等版本”变成“盯三件事”
既然没有大版本发布，那如何保持对平台进展的敏感度？我个人的方法是用三个信息源互相印证。
第一，浏览器发布日志。Chrome、Safari、Firefox每次更新都有新特性列表，尤其是Chrome的“New in Chrome”系列，信息密度很高。第二，CSSWG的规范状态页面和GitHub讨论。如果说浏览器发布日志是“结果”，那CSS工作组的项目列表就是“前瞻”。你可以看到每个模块处于Working Draft、Candidate Recommendation还是已进入多浏览器实现阶段，心里就有数。第三，MDN的更新日志、CSS Baseline状态和caniuse。这三者配合起来，基本能避免“以为支持其实不支持”的坑。
很多朋友抱怨现代前端的复杂度越来越离谱，但其实浏览器的能力演进逻辑反而比过去更简单了。以前你对HTML的认知可能几年才需要刷新一次；现在每隔小半年就有新的标签或CSS能力进入Baseline。保持阅读习惯是唯一的出路，但也不用恐慌——你不需要把所有新东西都背下来，只需在自己需要解决问题时，知道自己该去哪里查。
5.4 对团队的启发：渐进增强就是新常态
最后说说团队层面的感受。在旧版本时代，一个项目从HTML4升级到HTML5，像是一次集中改造，你会列一个长清单：哪些标签要换、哪些属性要删、是否要用canvas替代Flash。但在无版本时代，升级是高频小步推进的。你年初用<dialog>，年中上了容器查询，年底又把某个关键组件的颜色空间换成显示P3。这种变化不需要发布会，只需要团队内部形成“渐进增强”的共识。
我的实操建议是：在代码仓库里预留一份.browserslistrc或者使用“支持度表格”记录目标浏览器范围。每当一个新特性进入支持范围，就在相关样式或组件代码里添加清晰注释，说明从何时开始被允许使用。这比等待“统一大版本”有可操作性得多。
最后说点我自己的体会
做前端这些年，我花了不少时间追各种框架的大版本，却常常忽略Web平台本身的演进。直到认真把HTML和CSS这两条标准线的发展历史梳理一遍，我才发现那些看似最基础的“标记语言”和“样式表”，其实已经从一个需要整体订票上车的时代，变成了单车随到随走的时代。
如果你现在因为还在等待“HTML6”或“CSS4”而没有去尝试一些现代功能，我的建议是：从现在开始，把问题换成“我想要的这个特性，目前在项目目标浏览器里达到了什么Level”，比纠结版本号重要得多。版本号这个概念在Web标准圈里已经被永久存档，真正值得我们盯住的，是浏览器内核的更新日志、Baseline状态以及规范文档里每一处鲜活的修订记录。这不代表Web平台变慢了，恰恰说明它正在不知疲倦地往前跑。