1. 用户现在为什么会感觉割裂#

先想象一个游戏里的登录表单。用户希望它能输入中文，能 Tab 切换焦点，能粘贴验证码，密码管理器能自动填充，屏幕阅读器能读出 label。这些是 DOM 擅长的事。

再想象提交之后，整个表单像玻璃一样碎裂成粒子，每一片都经过 shader 扭曲、3D 翻转、辉光后处理，再飞散到场景深处。这些是 Canvas、WebGL、WebGPU 擅长的事。

过去的问题是，这两种体验很难发生在同一个对象上。

DOM 是浏览器的应用层 UI 系统。它有语义、布局、字体、输入法、选区、复制粘贴、焦点管理、表单控件、自动填充、浏览器翻译、查找、无障碍树和扩展生态。你写一个 <input>，背后不是一个矩形和几行事件监听，而是一整套浏览器能力。

Canvas 则是另一种模型：一块像素网格，一条命令式绘制管线。它适合游戏、图形编辑器、数据可视化、视频合成、3D 场景和 shader 效果。它给你的是自由，但你也要自己承担 UI 系统原本替你做掉的事。

这个分工在简单页面里没问题，但一到复杂产品就会刺痛：

• 游戏 UI 想要原生输入框和 IME，又想要 shader 转场。
• 设计工具想把真实网页放进无限画布，再对它旋转、缩放、加滤镜。
• WebXR 想在 3D 空间里显示一个可交互的 HTML 面板。
• 直播工具想把网页、字幕、摄像头和特效都放进同一条 GPU 合成管线。

用户真正感受到的割裂不是“技术栈不同”，而是：表单像网页时就不像游戏画面，表单像游戏画面时又不像一个正常网页表单。

开发者真正想要的也不是“把网页截图快一点”，而是一个更底层的原语：DOM 继续是 DOM，但它的视觉结果也能成为 Canvas/GPU 世界的一等输入。

2. 浏览器明明已经在用 GPU 合成 DOM，为什么不给开发者？#

现代浏览器内部早就在做合成层：页面里的 DOM、动画元素、视频、Canvas 都可能被分到不同 layer，再由 compositor 合成为屏幕上的一帧。

所以直觉上会觉得：既然浏览器内部已经把很多东西变成 GPU 可合成的表面，为什么不直接把某个 <div> 的纹理给 JavaScript？

难点不在“能不能画”，而在三个边界。

第一是安全与隐私。DOM 里可能包含跨域 iframe、跨域图片、被访问过的链接状态、拼写检查标记、系统主题、自动填充候选、用户偏好等信息。如果一个 API 允许把任意 DOM 像素读回 JavaScript，它就可能变成跨域信息泄露和指纹识别通道。

第二是渲染时序。DOM 的布局、绘制、滚动、CSS 动画和 Canvas 的绘制命令不是同一个抽象层。要把 DOM 的某一帧稳定地交给 Canvas，浏览器必须定义“什么时候快照”“什么时候触发更新”“主线程脚本和浏览器自己的绘制如何同步”。

第三是命中测试和无障碍。元素如果被画进 Canvas，但用户实际点击的是 Canvas 上的某个像素，浏览器要知道这个点击如何对应回真实 DOM；屏幕阅读器也要能理解画出来的东西不是一张死图，而是背后有语义元素。

HTML-in-Canvas 的设计基本都在围绕这三件事收边界：不是开放“任意 DOM 截图”，而是开放“Canvas 直接子元素的受控绘制”。

3. 旧方案为什么都差一口气#

在这个 API 出现之前，开发者一直在绕路。

4. HTML-in-Canvas 到底提供了什么#

WICG explainer 里的核心设计有三个部分：

1. layoutsubtree：让 <canvas> 的直接子元素参与布局、命中测试和无障碍相关流程，但它们不会像普通 DOM 那样直接显示出来，除非被显式画进 Canvas。
2. 绘制/上传方法：2D Canvas 使用 drawElementImage()；WebGL 使用 texElementImage2D()；WebGPU 通过 GPUQueue.copyElementImageToTexture() 上传。
3. paint 事件：当 Canvas 子元素的渲染发生变化时，浏览器通知开发者，让 Canvas 有机会同步更新。

一个接近底层 API 的概念化例子大概是这样：

<canvas id="stage" layoutsubtree></canvas>

<script>
const canvas = document.querySelector("#stage");
const ctx = canvas.getContext("2d");

const form = document.createElement("form");
form.innerHTML = `
  <label>
    Email
    <input value="still editable" />
  </label>
`;

canvas.appendChild(form);

canvas.addEventListener("paint", () => {
  ctx.clearRect(0, 0, canvas.width, canvas.height);
  const transform = ctx.drawElementImage(form, 40, 40);
  form.style.transform = transform.toString();
});
</script>

这里的关键不是那一次绘制，而是最后一行 transform 同步：浏览器需要知道这个真实 DOM 元素在 Canvas 画面里的位置，才能把点击、焦点、选区和无障碍命中区域对回正确的元素。

真实业务里，多数开发者不会直接碰这些底层方法，而是通过渲染框架使用。PixiJS v8.19 已经提供了 pixi.js/html-source 子路径：

import { Application, Sprite } from "pixi.js";
import { HTMLSource } from "pixi.js/html-source";

const app = new Application();
await app.init({ resizeTo: window });
document.body.appendChild(app.canvas);

const form = document.createElement("form");
form.innerHTML = '<input value="still editable" />';

app.canvas.appendChild(form); // 必须是 Pixi canvas 的直接子元素

const sprite = Sprite.from(
  new HTMLSource({ resource: form, autoUpdate: true }),
);

app.stage.addChild(sprite);

这里最关键的是：form 仍然是 DOM，输入框仍然能编辑；同时它又以 PixiJS texture 的形式进入场景，可以被当成 sprite 做缩放、旋转、滤镜、mask、shader 和后处理。

PixiJS 还提供 ElementImageSource，适合把某一刻的元素渲染结果冻结成不可变快照，用于碎裂、拖影、转场这类不需要持续交互的效果。

5. 新 API 真正不一样的地方#

HTML-in-Canvas 的价值不只是“更快截图”。它改变的是责任分配，也改变了用户能感受到的界面边界。

这让一种过去很尴尬的 UI 变得合理：用 DOM 写交互和语义，用 GPU 处理视觉和合成。

6. 用户会在哪些产品里感受到它#

7. 容易误读的地方#

8. 放进 Web 渲染演进史里看#

Web 渲染能力大致沿着这条线往前走：

HTML/CSS          声明式文档和应用 UI
Canvas 2D         命令式像素绘制
WebGL             可编程 GPU 图形管线进入浏览器
OffscreenCanvas   Canvas 绘制脱离主线程
WebGPU            更现代的 GPU 计算和图形接口
HTML-in-Canvas    DOM 渲染结果进入 Canvas/GPU 管线

这不是某个框架的小功能，而是 Web 平台的一次边界调整。

过去的默认分工是：

• DOM 负责语义、交互、可访问性。
• Canvas/GPU 负责自由绘制、shader、后处理和合成。

HTML-in-Canvas 让这两边第一次有了更直接的交换方式。它不取消分工，而是让分工后的结果可以重新组合。

原生平台早就有类似思想：Android 有 SurfaceTexture，Apple 平台有 IOSurface / Metal 相关 surface 共享，Flutter 有 texture 嵌入机制。Web 缺的不是 shader，也不是 DOM，而是两者之间受控、可同步、可解释的桥。

HTML-in-Canvas 正是在补这座桥。

9. 短中长期判断#

短期看，它会先出现在 PixiJS 这类渲染框架的 demo、教程和内部实验里。因为只有少数开发者愿意要求用户打开实验 flag 或注册 origin trial。

中期看，如果标准形态稳定、浏览器厂商逐步达成共识，Web 游戏 UI、设计工具预览、无限画布、可视化编辑器、在线直播合成会最先受益。这些场景都有同一个特点：它们需要 DOM 的正确性，也需要 GPU 管线的表现力。

长期看，HTML-in-Canvas 会成为“Web 作为一等媒体与创作平台”的一块拼图。它不会让 Native 失去意义，但会让更多复杂界面不再必须离开浏览器。

10. 结语#

写过 html2canvas 相关逻辑的人都知道，重写浏览器渲染器是一条没有尽头的路。

写过 CSS3DRenderer、iframe overlay 或 Canvas 自研 UI 的人也知道，两套渲染体系并排运行时，总会在交互、遮挡、性能或无障碍上露出代价。

HTML-in-Canvas 的重要性就在这里：它不是又一个截图库，而是浏览器开始承认一个现实需求：

DOM 应该继续负责它最擅长的语义和交互；GPU 也应该能够处理 DOM 的视觉结果。

对用户来说，这意味着复杂 Web 应用不必总在“像网页一样好用”和“像游戏、视频、3D 场景一样有表现力”之间切开。

这个 API 很小，但背后是 Web 渲染架构里一条很长的裂缝。裂缝一旦补上，很多过去只能 hack 的产品体验，就会变成平台能力。

参考与延伸#

• Chrome for Developers: Introducing the HTML-in-Canvas API origin trial
• WICG HTML-in-Canvas explainer
• Blink-dev: Intent to Experiment: HTML-in-canvas
• PixiJS Update - June 2026: HTML-in-Canvas textures

作者立场提示：本文从 Web 平台架构演进角度做分析，不构成任何具体框架或产品的技术选型建议。HTML-in-Canvas 当前仍处在实验阶段，生产可用性请以浏览器厂商和框架官方文档为准。