每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

浏览器的发展正处于一个奇怪的时期。尽管WebAssembly在服务器端取得了显著成功，但客户端的体验在过去十年间几乎没有根本改变。

不少技术爱好者认为，通过WASM访问原生Web API已经不再是难题，只需极少的JavaScript“胶水”代码即可实现。但关键问题并不是“是否可以”访问DOM，而是“为什么还要”访问它。如今，DOM似乎成了唯一的选择，但实际上，是时候让DOM和它那一系列错综复杂的API“退休”了。

“文档”模型的真实面貌

鲜有人真正意识到DOM有多庞杂。在Chrome中，document.body对象已包含超过350个属性，这还不包括其style属性中660个CSS属性。属性与方法的边界模糊不清，有些属性不过是隐藏的setter方法；一些getter方法甚至会触发即时的页面重排。此外，诸如onload、onmouseover等早期事件处理器仍被保留在API中，尽管几乎无人使用。

DOM并不轻盈，反而愈加臃肿。是否能感知这一点，取决于开发者是在制作网页，还是在开发Web应用。如今多数开发者已尽量避免直接操作DOM，虽然仍有人将“纯DOM”视为优于现代JS组件框架的“正统方式”。而诸如innerHTML这样的声明式功能早已无法满足现代UI开发的需求。DOM存在太多实现方式，却没有一种是令人满意的。

Web Components：错失良机的原生组件方案

Web Components本应成为Web平台上原生组件化的标准，但其出场时机过晚，加之API设计生硬，使其难以流行。其中Shadow DOM的引入更是带来了嵌套与作用域的复杂性，使许多开发者望而却步。其支持者往往语气近似辩解。

DOM的根本性问题，在于其源自SGML/XML的遗产，使得一切都变成了“字符串类型”——即所谓“stringly typed”。而React等框架虽然语法上看似XML，实际上并无此限制。如今开发者早已学会，不应把状态保存在DOM中，因为它无法胜任。

HTML十年如一日的停滞

HTML本身的问题更是根深蒂固。在过去十至十五年中，其结构几乎未曾改变。除了ARIA（无障碍访问）之外，鲜有实质性进展。语义化HTML未能兑现其承诺——比如至今没有 <thread> 或 <comment> 标签，即使这些已成为常见内容结构。语义化规范内容模糊，令人困惑。

HTML似乎始终执着于纸质出版物的模型，迟迟不愿拥抱超文本的本质，也未能给予用户清晰且可信的规则。HTML的管理早已从W3C转移至WHATWG，即各大浏览器厂商联盟，但他们迄今未能提供明确的未来愿景，仅在边缘上不断堆砌功能补丁。

CSS：结构混乱的布局系统

CSS的名声也不甚美好，但大多数人并不能准确说出其问题所在。问题的根源在于心智模型的错位——许多人将其视为约束求解器（constraint solver），这是误入歧途。

例如，使用百分比高度时，开发者可能以为设置两个50%高度的子元素，父容器就会被垂直平分。但由于CSS的布局流程是自内而外的（inside-out），在不知道父元素高度的前提下，这样的设置往往会被忽略，或者内容溢出。这是由于CSS并不会像某些布局引擎那样进行回溯或推理，而是“自上而下传约束，再自下而上传尺寸”。

在构建应用框架时需要outside-in的布局，而HTML默认偏向inside-out的文档式布局。这就是为什么垂直对齐在CSS中“很难”。

Flexbox的权衡与代价

使用display: flex确实可以解决上述问题。它允许合理划分空间、定义弹性增长/收缩。但这也引入了额外复杂度：每个子元素需先测量“自然尺寸”，再根据空间调整布局——这相当于布局过程要执行两次。对于嵌套结构甚至可能引发递归的计算爆炸，虽然在现实中很少出现。

为避免递归依赖，开发者需使用如contain: size、will-change等新CSS属性，以阻断DOM中流动的全局约束。这类机制透露了CSS中潜在的“分层”特性，但这些设计显然不是从头构建的，而更像是补丁堆叠。

DOM和CSS的原罪

在CSS中，继承（inheritance）仅适用于少数文字样式，如字体大小，而大多数属性（如边框）并不会继承。这揭示了CSS其实融合了两种截然不同的系统：一是基于继承的富文本样式系统；二是基于嵌套与包含的布局系统。两者共用一套语法，却行为不一致。将它们合并，注定是错误的。

此外，早期关于相对字体单位（如em）的设计，也已被逻辑像素与设备像素的概念取代，后者更符合用户直觉。

SVG：强大但笨重的图形系统

SVG作为可嵌入的矢量图形语言，提供了强大的图形功能，如路径、渐变、遮罩等，甚至支持多边形命中测试，这些CSS做不到。但SVG并非CSS的子集，也不是其超集。两者存在许多细节差异，例如变换矩阵的处理逻辑不同。SVG拥有自己的“怪癖”，例如必须将所有坐标序列化为字符串。

SVG与CSS的融合，反而造成了API设计的混乱。在许多情况下，开发者需在HTML、CSS与SVG之间权衡取舍，尽管它们本质上都作用于同一图形栈。

遗憾的API设计决策

Web平台中许多功能，都因版本1的设计过于仓促而停滞不前。例如：

• text-ellipsis 仅能处理单行文本，无法应用于段落；

• position: sticky 实用但常常出现诡异行为；

• z-index 缺乏相对层级控制，造成混乱的“+1/-1”战争。

这些问题反映出早期API设计中缺乏对长期演进的思考，而后续也未能通过模块化与可组合的方式解决。

Canvas：一个笨拙的“重绘”出口

近年来出现的“HTML in Canvas”提案，试图将HTML内容绘制到Canvas中，以获得完全的视觉控制。然而，这种方式本质上是将DOM强行嵌入Canvas中，为了保留布局与可访问性，最终反而限制了用途。

例如，若要绘制一个旋转立方体，开发者需手动绑定命中检测区域，并响应绘制事件。这种做法无法支持3D交互，仅能提供2D层面点击检测。更为关键的是：开发者必须接管元素所有交互责任，只为自定义其渲染方式。

这种Canvas方案，看似“可编程”，实则不过是无奈之举。当开发者想要在UI中实现DOM无法提供的功能（如内容虚拟化、定制交互、特殊视觉效果），却又不得不借助笨拙的Canvas与DOM组合，这无疑是对系统架构的一种拷问。

真正的出路：向下开放底层能力

Canvas并非无解，但它缺乏对系统字体、文本排版API与UI工具的原生支持。开发者甚至需自行实现断词、换行与测量功能，仅为实现“包裹文本”。

真正的解决方案，应是开放底层图形系统，而非继续在HTML/CSS/SVG之上堆砌补丁。这种“自上而下”的改造注定难以奏效。取而代之的应是“向下暴露原始能力”，让用户空间与底层逻辑一致，这正是良好内核设计的核心原则。

例如，Use.GPU 项目展示了基于WebGPU构建的HTML-like布局渲染系统，其使用Flex模型实现高效而简洁的UI布局——无DOM、无CSS，仅使用可组合的布局组件与着色器，定位直观、行为明确，甚至实现了垂直居中这种CSS难题。

这一系统展示了：无需HTML/CSS/SVG的沉重历史包袱，仅靠简洁的树状视图与渲染结构，即可完成DOM 90%的任务。

下一步该往哪里走？

从根本上重新设计DOM，去除所有历史遗留，可以为浏览器带来多线程、多来源、异步友好的全新架构。现代浏览器引擎已是多进程架构，但它们的设计仍然受限于1990年代的DOM模式。

另一些实验性浏览器项目，如Servo或Ladybird，也许能提出更清晰的替代方案。它们实现新功能时无需顾及历史兼容性，因此具备探索新范式的空间。

开发者应开始关注这些新兴技术，并对现有HTML/CSS/DOM系统保持警惕。重新思考UI工具链与平台基础设施，是时候了。因为，旧的DOM不再适应现代Web应用的需求——而新一代的Web，不应再背负它的遗产。