Why <canvas>?

By | 2 November, 2013

I’ve been playing around with the HTML5 <canvas> element for the best part of a year. I love it: it truly is the best thing since sliced bread. And yet I also find myself wondering … why? Why did the standards writers feel that HTML needed a canvas element? What purpose does it serve?

The trivial answer to my questions is neatly summarised in the Wikipedia article on the <canvas> element:

Canvas was initially introduced by Apple for use inside their own Mac OS X WebKit component in 2004, powering applications like Dashboard widgets and the Safari browser.

After which, I supposed, everybody thought: goody! We can use this to draw stuff on web pages. But that doesn’t answer my fundamental question: why?

Maybe I’m asking the wrong question. Maybe a better question is: what does the <canvas> element replace? And the answer to that question is simple. It replaces Flash.

Or at least it attempts to replace some bits of Flash, specifically the raster-based bits of it. One of the things the <canvas> element emphatically does not do is Scalable Vector Graphics – which gets its own <svg> element in HTML5.

So what purpose does Flash serve?

Flash has been around for a long time (see: origins). And it’s popular – there’s been times when it seemed to be taking over the web with Flash intros and Flash adverts. But even from its early days Flash has had its critics, for example Jakob Nielson’s ‘Flash: 99% Bad’ judgment back in 2000.

And even though the .swf tide seems to be finally ebbing, Flash is not going to go away. Adobe have released toolkits to make converting .swf to HTML5 (via the CreateJS JavaScript library) a lot easier for ‘professional’ users.

CreateJS is, to quote, “a suite of Javascript libraries & tools for building rich, interactive experiences with HTML5”. And the core of CreateJS is EaselJS“a Javascript library that makes working with the HTML5 Canvas element easy.” CreateJS is brilliant for developers who are used to working with Flash, particularly if they don’t want to confront the horrors of the <canvas> element’s JavaScript API.

But it’s still, in it’s way, another form of Flash. And even after 13 years, Nielson’s criticisms of the technology still resonate with me. Used poorly, the <canvas> element has the potential to:

  • encourage design abuse;
  • break web fundamentals – especially when it comes to accessibility and internationalization; and
  • distract from a website’s core values and message.

Now don’t get me wrong. I adore the <canvas> element. I’ve even become quite fond of the JavaScript API that sits behind the element. But I think developers need to think long and hard before they commit themselves to adding a canvas to a webpage. In particular:

  • What will the canvas add to the website?
  • How will the canvas play with the other parts of the website?
  • What will site visitors lose if they can’t see the canvas?
  • Are there better ways to achieve the website’s objective using other methods, such as SVG or CSS?

I believe – utterly – that, used well, the <canvas> element has the potential to revolutionize the web. My new question is: how?

Click click ...Tweet about this on TwitterShare on Google+Share on FacebookShare on TumblrShare on LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *