Does it make sense to create canvas-based UI components?

Question

While DOM still totally dominates the way we create UIs, does it make sense to create a bunch of entirely canvas-based UI components, like buttons, lists, horizontal/vertical groups, etc?

I know for sure that there will be a lot of drawbacks, but what would the possible advantages of such be?

For one, I'd say in general the visual integration with canvas will be much tighter.

Answer 1

The Zebra project has created a full component set which is rendered into a HTML5 canvas element. Here is a screenshot of the component sampler. I haven't used the framework, but it should give you an idea of how well the different browsers can render UI components.

Rotate the components and check the quality of line rendering (anti-aliasing), which is very different depending on the browser you use. Here's some more information regarding that problem:

• HTML5 Canvas avoid any subpixel rendering
• Poor anti-aliasing of text drawn on Canvas
• Subpixel anti-aliased text on HTML5's canvas element

Another project is Makepad, a webGL worker-based library and live code editor. Every visible part of the UI is rendered in WebGL, including all text on screen, rendered through the integrated text rendering engine.

It is still early phase for the project, but you can try out a live demo here. Makepad is open source, the Git repo can be found at github.com/makepad/makepad.github.io.

Answer 2

Using Canvas as a UI base is an excellent idea if you have > 200 elements. It's much, much faster to render than using DOM elements.

On iPhone Safari, 300 animated DOM elements runs at 3fps (frames per second), very slow.

If you use canvas, you can render > 300 elements and still achieve 30fps, which means smooth animation and transitions. I've tested this at length so I know it works.

The downside to Canvas (as someone else mentioned), is that search engines can't see your content. But if you are building an app that shouldn't be spidered and needs to run on mobile, then Canvas is the way to go.

Answer 3

For the last four years I have been building components for the canvas including buttons, dials, sliders, check boxes, radio buttons, color pickers, panes, windows, indicators, waiters, steppers, tabs, pads, etc. see http://zimjs.com/components/ for working examples.

The advantages are as follows:

1. The components can be customized in more or different ways than traditional HTML/CSS components and we can make more types of components. See http://zimjs.com/docs.html for examples.
2. It is often important when making interactive works to embed the components right in the app or game. This is difficult to do by overlaying HTML components when taking into account scaling apps.
3. There is definitely tighter integration when dragging panels, animating components, scaling components, working with canvas library events (ZIM and CreateJS use on() method which has benefits - canvas components can make use of this).

I love working with Canvas components - it saves lines of code and I don't have to switch between systems. Just a reminder... the format of CSS is basically the same as an object literal in code. I would rather format my components in code any day rather than CSS - personally, I find it much easier to work in one system.

In terms of screen reader results for interface - many canvas creations are not suited for visually impaired. It can still be done, as pointed out, if applicable.

One final comment... consistency is an important design principle but variety is the spice of life. I do not think we should be relying on a homogeneous interface system. There should be room for growth, experimentation and exploration.

Answer 4

That sounds like a bad idea. You will lose much accessibility that the user expect e.g. focus and tabbing. Or it will be a lot of work for you to implement all that.

It's much better to use HTML5 and CSS3 for such things. There is many JavaScript GUI Frameworks available e.g. see 15 Javascript Web UI Libraries, Frameworks and Toolkits.

Answer 5

We've tried something like this but finally came up with the idea that the world is not ready yet )

You should keep in mind following

• js always should be enabled. Nowadays one can consider it not a big deal, but nevertheless it worth to mention.
• html/css is actually traditional and constantly evolving stack of standards, sooner or later you'll feel the need in having some descriptive language to reduce repeating code in your canvas rendered UI-components. And there are two options here - to try to invent something proprietary, which actually could be fun and interesting, but can have some very sad consequences. The second way is to reimplement html/css not to confuse third party developers. But, wait a minute, we've already have html/css engine )))
• events and, therefore, user experience. Jonas is right. Trying to reimplement even a subset of js event model to make it more comfortable to develop canvas rendered components is hard. Some issues even are unsolvable.

So, it is actually interesting experience, but I would not recommend.

Answer 6

Here is why I am choosing to do this:

1. My resume will render the same across all browsers.

2. I can re-use the code in my Go (Google Go) project. I am using SFML to set pixels, so as long as I don't try anything super "clever" the code will transcribe easily.

3. It's good practice, and while it's bad to re-invent the wheel, someone has to know how to do this.

Answer 7

I developed a JavaScript library that lets users create user interfaces using the canvas element. You can build UI elements of different types and you can event create your own types of elements like a tetris piece, a sudoku...

This is the library: canvasui-js.com