创建基于画布的UI组件是否有意义?

时间:2011-07-28 09:43:20

标签: javascript user-interface html5 dom canvas

虽然DOM仍然完全支配我们创建UI的方式,但创建一堆完全基于画布的UI组件(如按钮,列表,水平/垂直组等)是否有意义?

我肯定知道会有很多弊端,但这样做的可能优点是什么呢?

首先,我会说与画布的视觉整合会更加紧密。

7 个答案:

答案 0 :(得分:43)

Zebra项目创建了一个完整的组件集,该组件集呈现为HTML5 canvas元素。以下是组件采样器的屏幕截图。我没有使用过该框架,但它应该让您了解不同浏览器在呈现UI组件方面的表现。

enter image description here

旋转组件并检查线条渲染(抗锯齿)的质量,这取决于您使用的浏览器。以下是有关该问题的更多信息:

另一个项目是Makepad,一个基于webGL工作者的库和实时代码编辑器。 UI的每个可见部分都在WebGL中呈现,包括屏幕上的所有文本,通过集成的文本呈现引擎呈现。

Makepad - a webGL worker-based library and live code editor

该项目仍处于早期阶段,但您可以尝试live demo here。 Makepad是开源的,可以在github.com/makepad/makepad.github.io找到Git repo。

答案 1 :(得分:26)

如果你有>使用Canvas作为UI基础是一个很好的主意。 200个元素。渲染比使用DOM元素要快得多。

在iPhone Safari上,300个动画DOM元素以3fps(每秒帧数)运行,非常慢。

如果使用画布,则可以渲染> 300个元素仍然可以达到30fps,这意味着平滑的动画和过渡。我已经详细测试了这个,所以我知道它有效。

Canvas(正如其他人提到的)的缺点是搜索引擎无法看到您的内容。但是如果您正在构建一个不应该被蜘蛛侠并且需要在移动设备上运行的应用程序,那么Canvas就是您的选择。

答案 2 :(得分:20)

没有

还记得2000年初吗?当每个人都认为利用Flash创造最令人作呕的网站导航比赛会很酷吗?

我们不要再这样做了。

可以使某些 UI元素由canvas进行美化,但请记住,网页抓取工具(如Google)或禁用了脚本的用户无法访问这些元素,等

值得注意的是,HTML Canvas规范中有一个部分strongly advise against trying to create text-editing controls in Canvas.

  

我肯定知道会有很多缺点,但这样做有什么好处呢?

您可以使用Canvas向页面添加许多漂亮的元素。有些东西可以变得非常漂亮而不会以任何方式侵入或改变页面导航。也许网站的标识会在程序上“增长”或发光或以其他方式变得更复杂。其他背景动画效果可能非常整洁。

还有交互式图像,例如您想要图表或细分或爆炸视图的网站,您可以导航以检查某些内容的各个部分(化学结构,生物体,新车)。诸如图表和游戏之类的可视化交互式媒体是Canvas的最佳用例。

在强调页面的UI方面,如果页面的Canvas元素不存在,页面也应该完美地工作。

但是更换按钮?替换文本字段?替换列表?绝对不。那些永远不应该是Canvas的领域。

答案 3 :(得分:8)

在过去四年中,我一直在为画布构建组件,包括按钮,拨号盘,滑块,复选框,单选按钮,颜色选择器,窗格,窗口,指示器,服务员,踏步机,标签,垫等。请参阅{ {3}}用于工作示例。

http://zimjs.com/components/

优点如下:

  1. 组件可以以比传统HTML / CSS组件更多或更多的方式进行自定义,我们可以制作更多类型的组件。有关示例,请参阅Dial and Slider in ZIMjs for Canvas
  2. 制作互动作品时,通常很重要 应用程序或游戏中的组件。这很难做到 在考虑扩展应用程序时覆盖HTML组件。
  3. 在拖动面板,动画组件,缩放组件,使用画布库事件(ZIM和CreateJS使用on()方法时,肯定有更紧密的集成,这有益处 - 画布组件可以使用它)。
  4. 我喜欢使用Canvas组件 - 它可以节省代码行,而且我不必在系统之间切换。只是提醒一下...... CSS的格式与代码中的对象文字基本相同。我宁愿在任何一天用代码格式化我的组件而不是CSS - 就个人而言,我觉得在一个系统中工作要容易得多。

    在界面的屏幕阅读器结果方面 - 许多帆布创作不适合视障人士。如上所述,如果适用的话,它仍然可以完成。

    最后一个评论...... 一致性是一个重要的设计原则,但多样性是生活的调味品。我认为我们不应该依赖于同构接口系统。应该有增长,实验和探索的空间。

答案 4 :(得分:3)

这听起来不错。您将失去用户期望的可访问性,例如重点和标签。或者,实现所有这些将是很多工作。

将HTML5和CSS3用于此类事情要好得多。有许多JavaScript GUI框架可用,例如见15 Javascript Web UI Libraries, Frameworks and Toolkits

答案 5 :(得分:3)

我们尝试过这样的事情,但终于提出了世界尚未准备好的想法)

你应该记住

    始终应该启用
  • js。如今人们可以认为这不是什么大问题,但值得一提。
  • html / css实际上是传统且不断发展的标准堆栈,迟早你会觉得需要使用一些描述性语言来减少画布渲染的UI组件中的重复代码。这里有两个选择 - 试图发明一些专有的东西,实际上可能很有趣,但可能会产生一些非常悲伤的后果。第二种方法是重新实现html / css而不是混淆第三方开发人员。但是,等一下,我们已经有了html / css引擎)))
  • 事件,因此,用户体验。乔纳斯是对的。尝试重新实现甚至js事件模型的子集以使开发画布渲染组件更加舒适很难。有些问题甚至无法解决。

所以,这实际上是有趣的经历,但我不建议。

答案 6 :(得分:0)

这就是我选择这样做的原因:

  1. 我的简历将在所有浏览器中呈现相同的内容。

  2. 我可以在Go(Google Go)项目中重复使用该代码。我使用SFML设置像素,所以只要我不尝试任何超级“聪明”的代码就可以轻松转录。

  3. 这是一个很好的做法,虽然重新发明轮子是不好的,但有人必须知道如何做到这一点。