虽然DOM仍然完全支配我们创建UI的方式,但创建一堆完全基于画布的UI组件(如按钮,列表,水平/垂直组等)是否有意义?
我肯定知道会有很多弊端,但这样做的可能优势是什么呢?
首先,我会说一般来说,与画布的视觉整合会更紧凑。
没有。
还记得2000年初吗?当每个人都认为使用Flash创造最令人作呕的网站导航的竞赛会很酷吗?
我们不要再这样做了。
可以使用画布来修饰一些UI元素,但请记住,网页抓取工具(如Google)或禁用了脚本的用户都无法访问这些元素,等等。
值得注意的是,HTML Canvas规范有一个部分,他们strongly advise against trying to create text-editing controls in Canvas.
我肯定知道会有很多弊端,但这样做的可能优势是什么呢?
您可以使用Canvas将很多漂亮的元素添加到页面中。有些东西可以变得非常漂亮而不会以任何方式侵入或改变页面导航。也许网站的标识会在程序上“增长”或发光或以其他方式变得更复杂。其他背景动画效果可能非常整洁。
还有交互式图像,例如您想要图表或细分或爆炸视图的网站,您可以导航以检查某些内容的各个部分(化学结构,生物体,新车)。诸如图表和游戏之类的可视化交互式媒体是Canvas的一些最佳用例。
在强调页面的UI方面,如果页面的Canvas元素不存在,页面也应该完美地工作。
但是更换按钮?替换文本字段?替换列表?绝对不。那些永远不应该是Canvas的领域。
Zebra项目创建了一个完整的组件集,该组件集呈现为HTML5 canvas元素。以下是组件采样器的屏幕截图。我没有使用过该框架,但它应该让您了解不同浏览器在呈现UI组件方面的表现。
旋转组件并检查线条渲染(抗锯齿)的质量,这取决于您使用的浏览器。以下是有关该问题的更多信息:
另一个项目是Makepad,一个基于webGL工作者的库和实时代码编辑器。 UI的每个可见部分都在WebGL中呈现,包括屏幕上的所有文本,通过集成的文本呈现引擎呈现。
该项目仍处于早期阶段,但您可以尝试一下live demo here。 Makepad是开源的,Git回购可以在github.com/makepad/makepad.github.io找到。
如果您有> 200个元素,那么使用Canvas作为UI基础是一个很好的主意。渲染比使用DOM元素要快得多。
在iPhone Safari上,300个动画DOM元素以3fps(每秒帧数)运行,非常慢。
如果使用画布,则可以渲染> 300个元素并仍然达到30fps,这意味着平滑的动画和过渡。我已经详细测试了这个,所以我知道它有效。
Canvas(正如其他人提到的)的缺点是搜索引擎无法看到您的内容。但是如果您正在构建一个不应该被蜘蛛侠并且需要在移动设备上运行的应用程序,那么Canvas就是您的选择。
在过去的四年里,我一直在为画布构建组件,包括按钮,拨号盘,滑块,复选框,单选按钮,颜色选择器,窗格,窗口,指示器,服务员,踏步机,标签,垫等。请参阅http://zimjs.com/components/了解工作示例。
优点如下:
我喜欢使用Canvas组件 - 它节省了代码行,我不必在系统之间切换。只是提醒一下...... CSS的格式与代码中的对象文字基本相同。我宁愿在任何一天用代码格式化我的组件而不是CSS - 就个人而言,我觉得在一个系统中工作要容易得多。
在界面的屏幕阅读器结果方面 - 许多帆布创作不适合视障人士。如上所述,如果适用的话,它仍然可以完成。
一个最后的评论......一致性是一个重要的设计原则,但多样性是生活的调味品。我认为我们不应该依赖于同构接口系统。应该有成长,实验和探索的空间。
这听起来像个坏主意。您将失去用户期望的可访问性,例如重点和标签。或者,实现所有这些将是很多工作。
将HTML5和CSS3用于此类事情要好得多。有许多JavaScript GUI框架可用,例如见15 Javascript Web UI Libraries, Frameworks and Toolkits。
我们尝试过这样的事情,但终于提出了世界尚未准备好的想法)
你应该记住以下内容
所以,这实际上是有趣的经历,但我不推荐。
这就是我选择这样做的原因: