Show HN：Dropflow，一个适用于 node 或 `<canvas>` 的 CSS 布局引擎

总体反应与范围

• 许多人认为 Dropflow 非常令人印象深刻：本质上是一个可用于 Node 或 <canvas> 的独立 CSS 布局引擎。
• 它被视为在服务端渲染、图形和自定义 UI 场景中，填补了“没有引擎”和“完整浏览器”之间的空白。
• 有人认为这像是在浏览器里“重造一个浏览器”；也有人认为，确实存在面向特定用途、更轻量的引擎空间。

实现复杂度与规范

• 实现 CSS 布局，尤其是文本布局，被描述为非常困难：
  • 复杂性包括字形 shaping、RTL 文本、换行和下划线。
  • 相关知识被认为很晦涩；其中很多内容是从现有引擎和规范中逆向推导出来的。
• CSS2 被赞为一个扎实、连贯的基础；CSS3 则建立在其之上。
• 浏览器中的换行被描述为一种在断点处的贪心算法；浮点精度与整数运算之间的权衡是一个实际问题。

特性、缺口与相关引擎

• Dropflow 当前主要聚焦于 CSS2 风格的块级/行内布局，而不是 flexbox 或 grid。
• 有人认为缺少 flexbox 是一个重大限制；也有人指出，许多类文档布局并不需要它。
• 提到的计划包括：分页 / @page、表格、图片、更好的 PDF 示例。
• 作为对比提到了其他引擎和工具：Yoga（仅 flexbox）、Taffy（flex+grid）、litehtml、WebKit.js、Sciter、Satori、dom‑to‑image、html2canvas、PDF 库，以及商业 HTML‑to‑PDF 引擎。

使用场景

• 在不运行完整浏览器的情况下，进行服务端 HTML/CSS → 图片或 PDF 生成。
• 后端生成 Open Graph 图片、图表，或 node-canvas 图形。
• 可能成为富文本编辑器，或 canvas / WebGL 中 UI 的基础，避免使用 contenteditable。
• 也可能在桌面风格或类原生 UI 框架中发挥作用。

性能与渲染模型

• 有人对使用 CSS 布局将内容渲染到 canvas 以支持高吞吐量 UI（例如大数据网格、WebGL 纹理）很感兴趣。
• 关于 DOM 配合现代技术（contain、虚拟化）能否在大型表格场景中达到 canvas 性能，存在争论；不同人的体验并不一致。

可访问性、安全性与“黑盒网页”

• 人们强烈担忧基于 canvas 的应用会像早年的 Flash/Java 黑盒一样：
  • 更难检查、复制文本、屏蔽广告，或使用键盘导航。
  • 如果不手动重做，屏幕阅读器和整体可访问性都会较差。
• 也有人指出，在这类方案可能占主导之前，浏览器需要先提供明确的 canvas 可访问性 API。
• 原生的“CSS-in-canvas”被认为可能带来安全问题（例如访问过链接泄漏、跨源数据）。