第一次跑通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.