在 Web 开发领域，渲染性能的边界始终是被不断试探的核心议题。长期以来，DOM 树的操作成本与浏览器的重绘重排机制，限制了前端交互效果的想象力。随着 GPU 加速技术的普及以及 WebAssembly、WebGPU 等底层能力的开放，网页应用正在经历从“文档展示”向“富客户端体验”的范式转移。
在此背景下，一种名为 HTML-in-Canvas 的实验性技术近期在开发者社区引发了广泛关注。它试图打破传统 DOM 渲染与 Canvas 图形绘制之间的壁垒，为网页交互带来类似游戏引擎般的自由度。
HTML 也能跑 Doom 游戏了？？
技术观察 发自 前沿实验室
深度科技评论 | 专注互联网基础设施
不禁让人感叹，前端技术的演进速度已至如此境地。
指尖轻触，选中的区域瞬间呈现碎片化效果，视觉冲击力极强的炫酷感扑面而来。
不仅能渲染真人影像，在设计游戏化交互场景时更是游刃有余，同款射击破碎效果现已落地。
更有高手将网页设计为鱼眼镜头效果，且参数支持实时动态调整。
不止于此，海外开发者社区此刻正被大量酷炫的前端作品刷屏，令人目不暇接。
而这些创意，均源自一种正在悄然走红的实验性玩法——HTML-in-Canvas。
通俗来讲，这是一种将网页元素作为游戏画面进行渲染的 UI 设计新范式。
众多早期体验者纷纷表示，HTML-in-Canvas 或许是下一代网页交互形态的雏形。
我很少评价某项技术为“规则改变者”，但 HTML-in-Canvas 可能例外。这是一个“让 Flash 体验回归”的时刻。
毕生都在等待这样的 Web API 出现。
想象一下，将任意视觉效果应用于任何 HTML 元素。
那么核心问题来了，HTML-in-Canvas 究竟为何物？
顾名思义，这是一种将 HTML 元素“嵌入”Canvas 上下文进行渲染的技术方案。
其核心诉求归根结底在于：效率与控制权的平衡。
传统网页开发类似于“装配流水线”，HTML 定义结构、CSS 定义样式，最终由浏览器引擎负责排版与渲染。
换言之，虽然“素材”由开发者提供，但网页的最终呈现形态，很大程度上由浏览器内核决定。
而 Canvas 的逻辑则截然不同——
无 DOM 树、无布局系统、无预制组件，伊始仅有一块空白画布，开发者可随心所欲控制画面中的每一像素。
但也正因过于灵活，所有细节均需手动处理，故 Canvas 通常用于游戏开发、数据可视化等需从零构建的场景。
是否存在一种方案，能结合 HTML 的“开发便捷性”与 Canvas 的“渲染自由度”？
HTML-in-Canvas 正是为此而生。
其原理是将 HTML 元素“ rasterize（光栅化）为图像”，再投入 Canvas 中进行二次创作。
此举带来了三个显著的技术变革：
其一，过往难以实现的特效如今变得简易，因为操作对象已从 DOM 节点转变为像素数据。
传统 DOM 类似整体打包的容器（如按钮、图片、文本段），通常只能进行整体操作。
而像素则是构成这些元素的基本粒子，可实现单独控制。
因此，前端开发可借鉴游戏开发流程，例如为 UI 添加着色器、接入物理引擎，甚至逐帧控制像素运动。
其二，UI 布局的多元化得到显著提升。
既往网页开发默认 UI 为矩形结构，所有元素规整排列。
引入 Canvas 后，前端设计开始出现鱼眼、透视滚动等非线性布局，甚至是极具创意的异形设计。
例如，已有开发者实现了网页放大镜效果：
（尚处实验阶段，目前主要比拼创意实现）
此外，一个易被忽视的关键点在于，网页动画现在与游戏引擎采用了同一套渲染逻辑。
在传统前端开发体系中，动画的实现处境一度尴尬：
需在已“定型”的静态结构上，强制使其产生运动。
要么依赖 CSS 添加“动态”标签，要么使用 requestAnimationFrame 逐帧修改属性并进行插值计算。
而 HTML-in-Canvas 则反之——整个渲染过程，本质上是逐帧计算生成的。
因此，现今的网页视觉效果已接近游戏渲染画面。
众所周知，标准 HTML 本身无法直接运行《毁灭战士》（Doom）这类原生游戏。
因 Doom 基于 C 语言编写，需直接操作图形显存、内存及输入设备，而 HTML 仅作结构描述，不具备游戏运行时能力。
但如今，有人成功将 HTML 元素“嵌入”了 Doom 引擎中。
网页元素被实时“拍摄”为图像，降级为 Doom 可识别的 256 色，随后作为纹理贴图至游戏墙面。
故而现在可见 Doom 墙面上显示网页内容，且能随视角动作实时变化。
值得一提的是，虽然 HTML-in-Canvas 目前仍属实验功能，但已以提案形式进入 W3C（万维网联盟）/WICG（Web 平台孵化器社区组）体系——
这意味着，未来它有望纳入 HTML 标准体系，成为浏览器原生支持的基础能力。
因此，公测开启后吸引广泛关注也在情理之中。
（补充说明，类似构想早在 2016 年便被提出，当时因浏览器厂商认为应用场景不足而搁置，直至近期被谷歌重拾并推进。）
至于如何体验 HTML-in-Canvas，可参考社区提供的方案。
此处以 Chrome 浏览器 为例：
第一步：地址栏输入「chrome://flags/#canvas-draw-element」，查找并开启 HTML in Canvas 实验功能。
第二步：在代码的 <canvas> 标签上显式添加 layoutsubtree 属性。
第三步：随后即可通过 getContext(‘2d’) 获取画布上下文，调用 drawElementImage 方法，将 canvas 内的子元素直接绘制到画布上。
设置完成后即可开始创作。
有人脑洞大开实现了“碟中谍”式玩法，类似摸鱼场景，在桌面内嵌套了一个桌面。
虽看似“不正经”，但利用谷歌搜索 Hacker News 等功能均正常运作。
还有人将其应用于更“实用”的方向——构建了防垃圾邮件的动态登录界面。
输入框不再是普通表单，而是会扭曲、漂移、甚至带有干扰效果的动态界面。
对真人用户而言，依然可识别并输入（尽管体验略显复杂）。
但对脚本和爬虫而言，识别难度直接被拉满。
经网友一番体验后发现，这几乎是一种比 Pretext 更具颠覆性的前端技术。
看到对 Pretext 的反应后，我可以直言，世界尚未准备好接受 HTML-in-Canvas。
此处提及的 Pretext，是由 Midjourney 工程师 Cheng Lou 开源的一款热门前端工具。
它绕开浏览器的 DOM 排版系统，采用纯数学计算文字位置，排版速度较传统方式快数百倍。
且能让文字如流水般随意变形、绕开图片、甚至制作成游戏元素。
Pretext 热度如何？不仅作者发布帖子获千万浏览，且 GitHub 迅速揽星 4 万+。
然而现今，若说 Pretext 是将“文字排版权”从浏览器手中收回，那 HTML-in-Canvas 则是将“整个界面渲染权”一并接管。
难怪 Vercel CEO 感叹，网络最辉煌的日子还在前方。
在他看来，网络是 AI 的天然载体。
大语言模型最擅长生成 HTML、CSS、JS 代码，而浏览器则是所有人的代码编辑器——无需缴纳“平台税”，无需等待审核，打开即用。
且已能观察到，一些底层能力正在全面爆发。
包括 HTML-in-Canvas 在内，WebGPU、WebAssembly 等既往难以想象的技术，现已快成标配。
因此，未来 Web 的性能天花板大概率会被直接掀翻，今后网页可能“会像游戏一样惊艳、一样天马行空”。
当然最关键的是，HTML-in-Canvas 让大家意识到，生成式 AI 才是 UI 的终极形态。
每个人看到的界面都可能不同，每一帧都恰到好处。
故从这个角度而言，AI+UI 的玩法探索，HTML-in-Canvas 可能仅是起点。
HTML-in-Canvas 项目地址：
尽管 HTML-in-Canvas 展示了令人兴奋的可能性，但在技术落地层面仍面临不少挑战。首先，无障碍访问（Accessibility）是一个不可忽视的问题。当 HTML 元素被转换为 Canvas 像素后，屏幕阅读器可能无法正确识别内容，这对残障用户的体验将造成阻碍。
其次，SEO（搜索引擎优化）也可能受到影响。搜索引擎爬虫通常依赖 DOM 结构来理解页面内容，纯 Canvas 渲染可能导致内容索引困难。此外，文本选择、复制粘贴等基础交互习惯的改变，也需要用户重新适应。
总体而言，HTML-in-Canvas 代表了 Web 技术向高性能、高自由度方向演进的重要趋势。它未必会完全取代传统 DOM 开发，但在数据可视化、互动营销、游戏化网页等特定场景下，具有巨大的应用潜力。随着标准的完善与工具链的成熟，这项技术有望成为构建下一代沉浸式 Web 体验的关键基石。
