HTML-in-Canvas API：DOM 与 Canvas 的终极融合
The HTML-in-Canvas API origin trial
长期以来，Web 开发者在构建高交互视觉应用时，总要在 DOM 的语义丰富性和 Canvas 的底层图形性能之间艰难取舍。Chrome 推出的 HTML-in-Canvas API 起源试验彻底打破了这一僵局。该 API 允许将 DOM 内容直接绘制到 2D Canvas 或 WebGL/WebGPU 纹理中，同时保留完整的交互性、可访问性及浏览器原生功能。这意味着开发者无需再为了性能牺牲文本选择、复制粘贴或屏幕阅读器支持。无论是 3D 场景中的交互式 UI，还是复杂的 Web 应用，现在都能享受两者的最佳特性，让曾经不可能的体验成为现实。
通过结合 HTML 与底层图形处理，你可以创造出此前无法实现的体验。
HN 评论区
30- mrec
嗯，暂时还不太清楚这如何避免潜在的隐私泄露，比如将 DOM 超链接绘制到 Canvas 上，然后从像素数据中抓取它们的“已访问”状态颜色。
或者我可能有点落伍了；我很久没做严肃的 Web 开发了。
- artpar
我曾想实现一个完全基于 Canvas 的原生工作区，起初是用纯 HTML 实现和“伪 Canvas”方案，但即使面板数量适中（约 50 个），响应速度也大幅下降。所以我转向了基于“真 Canvas”的新实现，并解决了面板和交互的问题。
在性能方面，这种方法效果好得多（能轻松处理 1000+ 个面板/嵌套面板，帧率保持在 60+ fps），但每个面板的实现复杂度变得非常高。比如，我无法直接使用 Markdown 渲染 JS 库或任何第三方 UI 组件。而且，频繁修改往往会导致性能严重下降。
目前我有文本/Markdown/图片/音频/视频和 PDF 面板（支持拖放文件）。
我在想是否应该重新尝试，用 HTML-in-Canvas API 来实现。不过我担心如果没人看到好处或使用量不足，这个 API 会不会被弃用？
- Ian_Macharia
太棒了！我正在开发一个由 AI 驱动的运动图形和视频生成器，最大的限制就是 HTML 和 Canvas 无法良好协作。某些视觉效果虽然看起来很酷，但会严重影响性能，所以我不得不做出妥协。我真心认为，这是我们在 Web 上实现 After Effects 级别 AI 运动图形功能前所需要的最后一块拼图。
对此非常期待！
- hollowturtle
天哪，我多么希望有一个像 Skia 那样的独立无障碍和文本布局 API，从而彻底抛弃 DOM。
- chrismorgan
（2026 年 5 月）