我正在开发一个 UI 将基于 Web 的应用程序。目标浏览器仅限 Internet Explorer
我想知道，对于 UI，什么时候使用 Canvas 并自己绘制所有元素而不是使用标准 HTML 元素会变得更好？
或情况是，如果您与HTML元素有用的东西，您应该只使用画布？
理想情况下，我正在寻找讨论或答案的链接以及一些解释原因的示例。如果只是取决于你喜欢什么，那就说吧，否则有什么考虑吗？
谢谢。
【问题讨论】：
标签： performance html canvas
请阅读我对"Does it make sense to create canvas-based UI components?"的回复。
简而言之，这是个坏主意。
Canvas spec itself gives a laundry list of reasons why it is bad to make UI controls in canvas. 可访问性是一场噩梦。引用规范：
作者应避免使用画布元素实现文本编辑控件。这样做有很多缺点：
- 必须重新实现插入符号的鼠标放置。
- 必须重新实现插入符号的键盘移动（可能跨行，用于多行文本输入）。
- 必须实现文本字段的滚动（水平滚动用于长行，垂直滚动用于多行输入）。
- 必须重新实现复制粘贴等原生功能。
- 必须重新实现拼写检查等原生功能。
- 必须重新实现拖放等原生功能。
- 必须重新实现页面范围的文本搜索等原生功能。
- 必须重新实现特定于用户的本机功能，例如自定义文本服务。这几乎是不可能的，因为每个用户可能安装了不同的服务，并且可能存在无限多的此类服务。
- 必须重新实现双向文本编辑。
- 对于多行文本编辑，必须为所有相关语言实现换行。
- 必须重新实现文本选择。
- 必须重新实现双向文本选择的拖动。
- 必须重新实现平台原生键盘快捷键。
- 必须重新实现平台原生输入法编辑器 (IME)。
- 撤消和重做功能必须重新实现。
- 必须重新实现辅助功能，例如插入符号或选择后的放大。
【讨论】：
是不是你应该只在 HTML 元素不能做的事情时才使用画布？
是的，差不多。画布用于绘图 - 现在是 2D，将来是 3D。
顺便说一下，我不希望浏览器原生控件永远更快地在画布上绘制。您在现有实现之上添加了至少一层代码。
【讨论】：