北京
第一次跑通HTML-in-Canvas的时候，你会怀疑这是不是假的。真正的DOM，真正的CSS，真正的排版引擎，全部塞进Canvas里。写一个canvas.onpaint，调用drawElementImage()，浏览器就帮你把样式完整的HTML画进帧里。看起来很美好。
直到你开始写真正的应用。
多画布表面、尺寸变化逻辑、导出时机、React卸载、资源清理、重绘触发——还有那个经典问题：这个数字到底是CSS像素还是Canvas像素？浏览器原语的光环褪去，剩下的是一摊子生命周期管理。
所以我做了Prism。
先解释HTML-in-Canvas是什么。WICG的这份提案让Canvas直接渲染真实HTML元素，不是截图，不是html2canvas，不是SVG的foreignObject，是浏览器亲自把DOM画进Canvas帧。核心就三个东西：layoutsubtree属性让Canvas子元素参与布局，drawElementImage()把子元素画进去，onpaint在需要重绘时触发。
单表面场景下，这套API顺得可疑。但应用从来不是单表面。
裸API抛给你一堆必须回答的问题：哪些DOM元素是Canvas表面？谁来更新它们的边界？谁向浏览器请求新帧？组件卸载时怎么办？运行时销毁时怎么办？怎么等一帧就绪再导出？CSS像素和后备存储像素怎么区分？
一个React组件就能写成这样：用ResizeObserver监听尺寸，手动设置canvas.width/height，绑定onpaint回调，在清理阶段断开Observer、清空回调。不算糟，但也不是我想写的应用。再叠加上导出、多表面、变换同步、指针交互、路由切换、框架集成——还有"为什么这行代码在Safari里不一样"。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
