37
0Google I/O 2026 上，Chrome 团队推了一个很容易被低估的新 Web 平台特性：HTML-in-Canvas。
很多人第一眼看到这个名字，脑子里会冒出一句话：哦，不就是终于可以在 canvas 里写 HTML 了吗？
这理解不能说错，但太浅了。
HTML-in-Canvas 真正重要的地方，不是“Canvas 能不能塞一个 div”。它动的是前端一条存在了很多年的边界：DOM 负责语义、交互和浏览器能力，Canvas / WebGL / WebGPU 负责像素、图形和 GPU 管线。过去这两套世界像两个国家，边境线画得很硬。你要 DOM 的可访问性、复制、查找、翻译、表单和 DevTools，就老老实实待在 DOM 里。你要 shader、3D、游戏、复杂画布和极致视觉控制，就进 canvas，但很多浏览器能力要自己重造，或者直接放弃。
HTML-in-Canvas 的变化是：浏览器开始给这两个国家修桥。
说白了，它不是让 Canvas 变成 DOM，也不是让 DOM 消失。它更像是让真实 DOM 变成图形管线的一种输入。
这就有意思了。
先说它到底是什么
按 Chrome 官方介绍，HTML-in-Canvas 是一个实验性 API，目前已经进入 origin trial。它允许你把 DOM 内容直接绘制进 2D canvas，或者作为 WebGL / WebGPU texture 使用，同时保留交互、可访问性和浏览器内建能力。
人话版是：
你可以写一个真实的 HTML 组件，比如一个表单、一段富文本、一个设置面板、一个复杂卡片。它不是截图，不是手搓像素，不是用 JS 模拟 CSS。它仍然是 DOM。然后你可以把这个 DOM 的渲染结果画进 canvas，甚至贴到一个 3D 物体表面上。
更关键的是，它还尽量保留浏览器能力。
文本可以被选中，内容可以被复制，页面查找能找到，屏幕阅读器能读，浏览器翻译能处理，DevTools 能检查，扩展也可能继续工作。
以前 canvas 应用最尴尬的地方就在这里：画面看起来很高级，但对浏览器来说经常只是一张大图。用户看到的是文字，浏览器看到的是像素。用户以为这是界面，辅助技术可能只看到一块空白。
这就像你开了一家装修很豪华的店，但门口没有门牌，消防图也没有，导盲系统也进不去。普通人看着炫，真到基础能力上，全是坑。
HTML-in-Canvas 要补的，就是这个坑。
过去为什么这么难？
前端一直有两套 UI 世界。
第一套是 DOM 世界。
DOM 的好处不是“能写 div”这么简单。它真正值钱的是浏览器几十年积累下来的能力：文本布局、换行、国际化、双向文字、表单控件、焦点管理、选择复制、右键菜单、无障碍树、页面查找、浏览器翻译、自动填充、缩放、暗色模式、扩展、DevTools。
这些东西你平时不觉得牛，是因为浏览器替你兜底太久了。
第二套是 Canvas / WebGL / WebGPU 世界。
它的好处也很明显：你可以直接控制像素，进 GPU，做 3D，跑 shader，做游戏，做白板，做设计工具，做复杂可视化。Figma、Miro、Google Docs 这类复杂应用，很多地方都离不开这种底层图形能力。
问题是，这两套世界以前很难同时拿。
你用 DOM，就很难把一个真实按钮贴到 3D 模型上，然后让它被玻璃折射、被 shader 扭曲、跟着模型旋转。
你用 Canvas，就要开始重造很多浏览器已经做好的东西。比如文本换行、光标、输入框、复制粘贴、焦点、可访问性。重造到最后，你会怀疑人生：我不是做一个 3D 面板吗，怎么突然在写半个浏览器？
这就是 HTML-in-Canvas 的背景。
大多数人以为前端缺的是更炫的渲染 API。但真相是，前端真正缺的是一条能把“语义 UI”和“图形管线”接起来的路。
它怎么工作？
HTML-in-Canvas 的核心设计可以拆成几个部分。
第一，在
这一步的意思是：让 canvas 里面的子元素参与布局和 hit testing。也就是说，你可以把 DOM 子节点放到 canvas 里，它们会像真实 DOM 一样被浏览器布局、参与可访问性和交互计算。但它们不会自动显示出来。想显示，必须显式绘制。
第二，用 drawElementImage() 把 DOM 画进 2D canvas。
比如你有一个
第三，如果你在 WebGL 里，可以用 texElementImage2D；如果在 WebGPU 里，可以用 copyElementImageToTexture。
这一步才是很多 3D 开发者眼睛一亮的地方。因为 HTML 不只是画到 2D canvas，它还可以成为 texture。texture 意味着它可以贴到 3D 物体上，可以进 shader，可以被 post-processing 处理，可以成为沉浸式场景的一部分。
第四，要同步 transform。
这是最容易被忽略、但最关键的一步。
你看到的 HTML 已经被画到 canvas 里了，但真实 DOM 仍然要知道自己“在屏幕的哪里”。不然用户点击画面上的按钮，浏览器不知道该把这个点击交给哪个真实 DOM 元素；屏幕阅读器、hover、focus、选中文本也会错位。
所以 drawElementImage() 会返回一个 transform。你要把这个 transform 应用到元素的 CSS transform 上。3D 场景里则可以用 getElementTransform() 辅助计算。说白了，视觉位置和真实 DOM 位置必须对齐。
这也是为什么它不是“截一张图塞进 canvas”。截图不会有焦点，不会有输入，不会有可访问性，不会有浏览器查找。HTML-in-Canvas 玩的是活的 DOM。
这和 html2canvas 有什么区别？
很多人会问：这不就是官方版 html2canvas 吗？
不是。
html2canvas 文档自己说得很清楚，它会遍历 DOM，读取元素信息，然后构建一个页面表示。它不是浏览器截图。它能画对多少，取决于它理解多少 CSS、多少布局细节、多少边界情况。
这就像你照着网页临摹一幅画。画得再像，也还是临摹。
HTML-in-Canvas 更接近浏览器自己把那层真实 HTML 渲染结果交给你当素材。它不是第三方库猜浏览器怎么画，而是浏览器平台提供“把 DOM 绘制进 canvas / texture”的能力。
还有一种老办法是 DOM overlay。
比如你在 WebGL canvas 上面盖一个绝对定位的 div，看起来像在 3D 场景里。但它本质上是贴在画面外面的透明贴纸。它可以交互，但它没有真正进入 3D 管线。它不能自然被 shader 处理，不能真实贴在一个旋转的 3D 屏幕上，也很难和复杂后处理融在一起。
DOM overlay 像把字幕贴在电视屏幕外面。
HTML-in-Canvas 是把字幕送进画面信号里。
差别就在这。
它带来的第一个变化：Canvas 应用不用再那么“装瞎”
Canvas 应用有个老问题：用户看得到，浏览器看不懂。
你在 canvas 里画了一个图表，用户看到坐标轴、图例、tooltip、按钮。但对浏览器来说，那可能就是一堆像素。你要想支持无障碍、搜索、复制、翻译、右键、自动填充，就得自己额外维护一套 fallback DOM 或自定义逻辑。
很多团队不是不知道该做，而是成本太高。
结果就是大量 canvas 应用变成“视觉上很强，浏览器能力很弱”。尤其是复杂白板、设计工具、图表工具、游戏 UI、3D 场景，一旦进入 canvas，很多普通网页里默认免费的能力突然都变成工程债。
HTML-in-Canvas 的价值，是让真实 DOM 可以继续存在于浏览器语义系统里，同时又能被画进 canvas。
这对大型 canvas-based 应用很重要。比如官方提到 Google Docs、Miro、Figma 这类重量级 Web 应用。它们不一定会马上把所有 UI 改掉，但某些复杂组件、嵌入式面板、文本区域、可访问内容，未来有机会少写很多自研逻辑。
你以为这只是省几行代码。
不，这是把“可访问性”和“浏览器能力”从补丁变回地基。
第二个变化：3D 和 WebXR 终于能吃上真实 Web UI
做过 WebGL / Three.js / WebXR 的人都知道，3D 里的 UI 很折磨。
你想在 3D 场景里的一个电脑屏幕上放一个网页界面。简单做法是贴一张图片，不能交互。高级一点，用 canvas texture，自己画内容。再高级，用 DOM overlay，让一个 HTML 面板跟着 3D 位置走。但它经常有遮挡、透视、事件、深度关系和真实嵌入感的问题。
所以很多 3D UI 最后都变成手搓。
按钮自己画，输入框自己写，布局自己算，hover 自己做，focus 自己接，事件自己 raycast。写着写着，你不是在做产品，你是在复刻浏览器。
HTML-in-Canvas 的想象空间就在这里：你可以用 HTML / CSS 写 UI，再把它作为 texture 放进 3D 场景。
Three.js r184 已经加了 HTMLTexture。PlayCanvas 也有 HTML-in-Canvas 文档，讲如何把 live HTML / CSS 渲染成 WebGL texture，并保留 hit testing、focus 和 accessibility。
这说明生态已经开始接线了。
对游戏、WebXR、沉浸式官网、3D 产品展示来说，这不是小改动。以前你要在“网页 UI 的成熟能力”和“3D 世界的真实嵌入感”之间选一个。现在至少有机会两个都要。
当然，别激动过头。
3D transform、hit testing、texture 更新、fallback、浏览器兼容，还是工程活。HTML-in-Canvas 不是仙丹，它只是把最底层那堵墙打开了一扇门。
门开了，不等于路铺好了。
第三个变化：AI Agent 更容易读懂“视觉应用”
这个点很多人会忽略，但我觉得很关键。
Google 在 I/O 2026 的语境里，不只是讲 Web UI，还在讲 agentic web。HTML-in-Canvas 官方介绍里也提到，内容如果仍然是 DOM，爬虫和 AI agent 可以更容易索引和读取 2D / 3D 场景里的文本。
这句话背后其实很重。
AI agent 要操作网页，最怕什么？怕界面只有像素，没有语义。
如果一个按钮只是 canvas 上的一块蓝色矩形，agent 要理解它，只能靠视觉识别、坐标推断、截图 OCR。能做，但脆。像让人隔着毛玻璃修电路。
如果那个按钮背后仍是 DOM，里面有真实文本、真实 role、真实 input、真实 form、真实可访问性信息，那 agent 操作它就稳定得多。
这也是为什么我说 HTML-in-Canvas 不是单纯视觉特性。它和 AI 原生 Web 是有关系的。未来的 UI 可能既要被人看，也要被 agent 读；既要能进 GPU 管线，也要保留语义；既要炫，也要能被浏览器工具理解。
很多人以为 AI 时代的 UI 会变成一堆生成出来的炫酷画面。
但真相是，AI 时代更需要结构化 UI。
没有结构，agent 就只能猜。猜得越多，系统越不可靠。
第四个变化：前端分工会重新洗牌
过去前端经常有一种隐形分工：
做业务页面的人在 DOM / CSS / React 里打转。
做创意视觉、游戏、3D、白板、设计工具的人在 Canvas / WebGL / WebGPU 里打转。
两边互相看不上也互相羡慕。DOM 这边觉得 canvas 那边炫但不好维护；canvas 那边觉得 DOM 这边啰嗦但能力成熟。
HTML-in-Canvas 会让这个分界变薄。
未来一个前端工程师可能不能只懂“组件怎么写”，也不能只懂“shader 怎么跑”。更值钱的是你能不能理解 UI 的三层：
语义层：这个界面对用户、浏览器、辅助技术、agent 来说是什么。
交互层：用户如何点击、输入、选中、复制、聚焦。
图形层：它如何被绘制、变形、合成、进入 2D / 3D / GPU 管线。
以前这三层经常绑在一起。DOM 页面三层都交给浏览器。Canvas 应用三层很多要自己写。
HTML-in-Canvas 的意义，是让这三层有机会重新组合。
这才是真正的变化。
但现在别把它吹成生产神技
这里要泼一盆冷水。
HTML-in-Canvas 现在还很早。
Chrome 官方写得很清楚，Chrome 148 到 150 是 origin trial。要本地测试，需要 Chrome Canary 149+，还要打开 chrome://flags/#canvas-draw-element。WICG explainer 也还在持续更新。TAG、Mozilla、WebKit 的相关讨论还没完全收束。
所以别看几个 demo 很炸，就开始喊“前端未来已来，马上重构所有项目”。
这事儿没那么简单。
第一，浏览器兼容是现实问题。你不能指望所有用户立刻支持。
第二，性能不是白送的。HTML-in-Canvas 通过 JS 驱动绘制，滚动、动画、频繁 texture 更新都要评估。把一大坨复杂 DOM 塞进 canvas，不会自动变快。
第三，安全和隐私有限制。跨源 iframe、跨源资源、用户敏感状态，不可能让你随便画进 canvas 再读像素。
第四，工程复杂度还在。特别是 3D 场景里的 transform 同步，想做得稳定，需要框架和引擎继续封装。
所以正确姿势是什么？
如果你是普通业务前端，现在不用焦虑，也不用为了跟风硬学。
如果你做 3D、游戏、WebXR、数据可视化、白板、设计工具、富文档编辑器，建议第一时间跟踪。不是马上上生产，而是做 demo、测边界、看生态封装。
如果你在做 AI 生成 UI 或 agent 可操作界面，那更要关注。因为这类技术会影响未来“界面如何既给人看，也给机器读”。
我真正看重的是什么
我看重的不是 API 名字。
前端这几年不缺新 API。很多 API 出来，热闹两天，然后消失在兼容性、复杂度和真实需求里。
HTML-in-Canvas 真正值得看的，是它背后的方向：浏览器正在承认，Web App 已经不是传统文档页面了。
现在的 Web 上有设计工具、视频编辑器、3D 展厅、AI coding IDE、白板、游戏、数据大屏、沉浸式课程、agent 操作界面。它们既需要 DOM 的语义和浏览器能力，也需要 GPU 的图形能力。
过去我们总在两边来回横跳。
要么在 DOM 里装作自己是原生应用。
要么在 canvas 里装作自己是浏览器。
HTML-in-Canvas 的出现，说明平台层开始补这块拼图。
这才是变革。
不是“Canvas 可以写 HTML 了”。
而是 Web UI 终于开始从二维页面，走向一个更混合的渲染模型：语义是语义，交互是交互，图形是图形，它们可以被组合，而不是被迫绑定在一套技术里。
最后说句实话
很多技术热点都喜欢用一句话把人骗进去：
“这会改变前端。”
大多数时候，这句话是空的。因为真正改变前端的，不是某个 API 多酷，而是它有没有改变开发者做选择的方式。
HTML-in-Canvas 这次有这个苗头。
以前你的选择是：要 DOM，还是要 Canvas？
以后可能变成：哪一层用 DOM，哪一层进 Canvas，哪一层交给 GPU，哪一层保留给浏览器和 AI agent？
这就是从“选阵营”变成“做架构”。
对普通人来说，这不是明天就能变现的新技能。
但对前端开发者来说，这是一个非常好的信号：浏览器平台还在进化，而且进化方向不是让你背更多黑话，而是把过去那些别扭的边界慢慢拆掉。
说白了，HTML-in-Canvas 不是终点。
它只是告诉你：Web UI 的墙，已经开始松了。
墙一松，新的东西就会长出来。
