Understanding the canvas in HTML5

Last week I tried to summarize key points about HTML5, the emerging standard that will affect the way Web pages — and other digital media — are created in the near future.

There were two aspects of HTML5 that I mostly left out. One is mobile (the interaction of HTML5 and the Internet on your phone). The other is how animated graphics and data visualizations will be handled natively in HTML5.

Today I’m going to tackle the graphics piece. In a later post, I will deal with mobile.

HTML has tags — such as <img> and <p> — which are used to indicate structural elements in a document, such as images and paragraphs. HTML5 retains many of the common tags and adds some new ones, such as <video> and <canvas>.

First, the canvas element does NOT replace regular images. We will still use the <img> tag to indicate photographs and illustrations, static maps and diagrams, in our Web pages.

Second, the canvas element is the specific part of HTML5 that is discussed as a replacement for the Flash Player plugin. (Note that video would NOT be handled by canvas in HTML5.)

I have been bookmarking some good resources about canvas in my Delicious, with the tags canvas + html5. I’m trying to keep the list small and useful.

So, what can the canvas do?

At its most basic, the tag sets out an area on the page (or screen) by setting a width and a height:

<canvas width="300" height="100"> </canvas>

You wouldn’t see anything but blank space. But you could use CSS to style that space — adding a border, for example. The border would enclose an area 300 pixels wide and 100 pixels high.

If you add something in between <canvas> and </canvas>, that is the “fallback content.” It will be visible only if the canvas element is not recognized by the client application — the Web browser.

So far, you’ve seen nothing new. Now I’ll add a necessary attribute — the ID.

<canvas id="tester" width="300" height="100"> </canvas>

It still does not do anything, but now it’s ready to do something.

Using that ID to identify the specific canvas element where graphics will appear, JavaScript will handle the creation of images, animation, etc. Yes, JavaScript.

We can add the script directly to the HTML page (preferably in the HEAD), or we can write JavaScript files (which are just plain text, with a filename ending with the extension .js) externally and call them in the HEAD of the HTML. Thus it’s easy to make these files modular and portable, and to use the same script on many pages in your site.

For an example of an interactive game that employs canvas (works in Firefox, Opera and Safari, but not IE), see Oooze. You can view source to see how the canvas element is used in the HTML. You can view the external JavaScript file too.

It’s a lot of lines of script, true. But if you made an interactive game in Flash (using ActionScript, which is a close cousin to JavaScript), that would also require a lot of lines of script.

Here’s an example that is not a game, but rather, a linear animation: Canvas Animation. If you view source, you’ll see that the <canvas> tag was not, in fact, used here. But the JavaScript demonstrates that this kind of animation can be done purely as JavaScript. NOTE that all the graphics are PNG image files, which are loaded in by the JavaScript. In other words, the color drawings were make in a drawing program. Each arm and leg and face, etc., is a separate PNG image file.

It’s not trivial to build an animation like this in Flash, I will readily admit. But you would not have to write any script to do it. Moreover, you would not need to upload 23 PNG files (total weight: 35.9 KB) to make the little guy in the red hat.

Data and the canvas element

Loading XML data into Flash files became about a hundred times easier with the advent of ActionScript 3.0. Flash can also “communicate via RTMP, HTTP, AMF, SOCKET to a wide range of server-side technologies” (source). How will canvas handle data inputs?

I’m not clear on this, but I think new APIs will have to be written to allow the kind of interaction between animations and data that we are accustomed to using when we author in Flash. Canvas uses APIs for 2D drawing, text, shadows, gradients, and I don’t know what else:

var context = tester.getContext("2d");

It’s hard for me to imagine when I read documents like this and this how anyone will ever produce great data interactives like this and this using canvas — but that might just be because it’s a fairly new specification at an early stage of development. Or maybe it’s because I’m not a hardcore programmer. Either way, I’m waiting to see how far canvas can go.

What I must say — for the present — is that it would be much harder to teach non-programmers (such as graphics reporters) to use canvas than it is to teach them to use Flash.

10 Comments on “Understanding the canvas in HTML5

  1. I wonder how many people who rushed out to get an iPad don’t even realize it won’t support Flash on the websites they visit.

    Too bad Apple is such a juggernaut – and that competing products for the iPad didn’t come out at the same time or earlier – because I’d really like to see Apple take a pounding for trying to eradicate Flash like they are. >:(

  2. Pingback: Recommended Links for April 19th | Alex Gamela - Digital Media & Journalism

  3. Although the canvas element is pure HTML5, one thing that hasn’t been mentioned a lot in the Flash vs. HTML5 debate is that if users upgrade to browsers that support HTML, they will also be upgrading to browsers that support SVG (scalable vector graphics). SVGs are basically XML files that describe vector graphics. They are very suited to manipulating through JavaScript frameworks like jQuery or Prototype and because they are plain text, ripe for compression. For things like data visualizations, SVG can be really powerful.

    All the major modern browsers have native SVG support except for — you guessed it — IE8 (plugins are available though). But IE9 is excepted to have native support as well, and let’s be honest, a lot of talk about HTML5 adoption is code for dropping support for IE6.

  4. Hey, Spencer, thanks very much for the comment! I looked into SVG a while ago, before I had a good grasp of XML, and I kind of dismissed them as overly complex to produce. I don’t mean to be a Flash sycophant, but it sure is easy to simply DRAW and animate in Flash.

    Do you think it’s reasonable to think that the general public will ever stop using the Web browser that is the installed default on most computers? I wonder …

  5. “It’s not trivial to build an animation like this in Flash, I will readily admit. But you would not have to write any script to do it. Moreover, you would not need to upload 23 PNG files (total weight: 35.9 KB) to make the little guy in the red hat.”

    This statement confuses the platform with its tools.

    You don’t have to write any ActionScript because your tools do it for you. There’s nothing stopping people from producing equivalent tools for JavaScript. Heck, I think the same exact tools might be able to output “.js” equivalents of many of today’s “.swf”s. (The languages are remarkably similar, since ActionScript is based on JavaScript.)

    You don’t need to use 23 .png files for the example: you can pack them all into one .js file as variables, say as base64-encoded data. The browser can then display them by using img tags with the “data” URI scheme. It sounds complicated, but this is almost exactly what ActionScript does under its hood–it’s just one line of JavaScript.

    HTML5 also comes with “Web Sockets”, which can handle any form of network communication.

    To my knowledge, any Flash you see on the Web can be implemented in JavaScript right now. It’ll work in Firefox, Safari and Google Chrome (though you’ll need to encode videos in two codecs to support all three browsers).

    There are new advantages to JavaScript which aren’t on the horizon in Flash. One is threading (running multiple tasks simultaneously: with threading, two processors can simultaneously work on one specially-written task and finish up to twice as quickly; again, Firefox, Safari and Google Chrome already support this). The other is multiple implementations: when a single-vendor product like Flash Player has security issues, they threaten 98 per cent of Internet users. In 2009, I remember at least one such vulnerability hackers found before Adobe. Vulnerabilities in Firefox, Safari, Google Chrome or even Internet Explorer do not have the same impact.

  6. Thanks for the comment, Adam. Especially this:

    “You don’t have to write any ActionScript because your tools do it for you. There’s nothing stopping people from producing equivalent tools for JavaScript.”

    I did not address this in my post, but it is my hope that Adobe will be able to “export for canvas” in an acceptable way. My fear is that such an export might generate inefficient script — think of the way Microsoft Word generates HTML (the horror! the horror!). Of course, it could be someone other than Adobe.

    With the recent protectionist move by Apple re: the iPhone SDK, there might be unnecessary roadblocks erected in the interests of corporate greed rather than open standards.

    You’re correct about the Flash Player security issue — that was a real black eye for Adobe.

  7. “With the recent protectionist move by Apple re: the iPhone SDK, there might be unnecessary roadblocks erected in the interests of corporate greed rather than open standards.”

    Corporate greed? That’s a gross oversimplification of what’s going on here, and really beside the point. As many have observed before me, Apple and Adobe are publicly held companies with fiduciary responsibilities to their respective shareholders. Apple does not exist to advance open source technologies, nor does Adobe. These companies exist to provide value to their shareholders, and each company is doing what it believes it must to be successful in that pursuit.

    It’s funny to me that Adobe has chosen to criticize Apple’s walled garden with respect to native application development when the Flash development environment is no different. If you want to author Flash, you use Adobe’s tools, period. Adobe’s value as a company hinges on its value to developers, and developers like the Flash authoring environment because it allows them to deploy across many platforms with one codebase.

    Apple, on the other hand, has built its business around offering consumers the highest quality user experience on the market. When Apple is successful to that end, the company sells more iPhones, iPads, MacBooks, etc. More devices sold means more value to their shareholders.

    Don’t buy the PR spin that Adobe is some sort of white knight to standards-based web development. Their goal as a company is for content creators and developers to use their software, plain and simple. The same way Apple supposedly wants developers locked in to Xcode, Adobe wants developers chained to the Flash authoring tool.

    Apple’s position, simply stated, is that native application development be done with their tools. Apple also believes that great things can be accomplished in the browser using HTML5, CSS, JS and H.264 video.

    Let’s pretend for a second that Apple had not written the new SDK to explicitly prohibit Flash authoring of native iPhone OS applications. Many developers would certainly jump at the chance to write applications once and deploy across iPhone OS and Android devices in one fell swoop. The problem with this scenario is that as the number of developers locked in to Adobe’s development environment increases, the control that Google and Apple have to move their respective platforms forward is severely diminished. Take for example the forward-facing camera that now appears to be a certain addition to the next generation of iPhone hardware. If developers are married to Flash as their iPhone app development environment, Apple now has to wait for Adobe to update the Flash authoring tool for new applications to take advantage of hardware improvements. Does anybody really believe that Adobe is going to push these kinds of updates out in a timely fashion, given the glacial pace they move at to release bug fixes to their $2k flagship product?

    I see nothing wicked in Apple’s desire to encourage developers to take advantage of new hardware capabilities when they are released to consumers, rather than on Adobe’s development schedule.

    Adobe can and will create tools that will author HTML5/CSS/JS solutions, but they will do so begrudgingly. Creating development tools for open standards is less attractive to them than pushing the Flash Player into mobile devices precisely because of developer lock-in. If you are using Adobe’s tools to create standards-based web applications, you are not locked into their platform.

  8. Didn’t care for the tone of some of the comments so I’ll respond in the same way.

    Regarding authoring of Flash swfs — this is not locked to Adobe’s software since you can easily code and build with the opensource FlexSDK without a stitch of paid for software – I’m not that broke so I don’t mind buying my software but the option is there.

    With regards to an earlier comment that it’s possible to build all the applications built in Flash (Flex apps for example) in HTML 5 Canvas that’s simply foolish — some enterprise apps are developed using tight integration with data and automated binding isn’t available in HTML 5 (not to say ‘someday’ it will be but I like to work with the reality of here and now). Flash has many more API’s available to the developer and more integration tools with big name sites than HTML 5 and will for some time to come.

    One of the biggest failures in the past 5 years has been the thought that you can do anything in Javascript that you can do with the Flash Platform tools. That’s very untrue and will remain so. Silverlight is much closer using C# for development than Javascript and HTML 5 (prototyping is utter and absolute garbage — no one talks about how unmaintainable prototype code is in the real world — has any one every tried to recreate a project built in Javascript? It’s a life changing moment. One of the reasons 4 years ago Flash abandoned it and followed the Java/C# model of development). And comparing Javascript to Actionscript is like comparing C# to Javascript — no comparison at all.

  9. Sigh, so much misinformation. From Adam Hooper:

    “You don’t have to write any ActionScript because your tools do it for you.” – Flash tools do not write ActionScript for you. Non-interactive animations in Flash simply do not use any script.

    “To my knowledge, any Flash you see on the Web can be implemented in JavaScript right now.” – This is not correct. As a random example, DRM. But the more relevant point is that you might as well say that all the images you see on the web could be created from scratch in Photoshop. Even if it’s true in theory, it doesn’t mean very much if it’s completely infeasible…

    From Danny DeBelius:

    “Adobe can and will create tools that will author HTML5/CSS/JS solutions, but they will do so begrudgingly.” – This is utterly unsupportable. Adobe makes (by far) the most popular professional tools for HTML/CSS/JS development. They have every reason to want that to continue.

    “The same way Apple supposedly wants developers locked in to Xcode, Adobe wants developers chained to the Flash authoring tool.” – Then it was mighty foolish of Adobe to release the open-source Flex SDK, eh? More importantly though, you’re glossing over the distinction between wanting something and legally prohibiting the alternatives. Nobody has any legal obligation to use Flash or to avoid its competitors – if Flash gets used, it’s because it’s solving somebody’s problems. The same cannot be said of obj-C, which Apple devs are legally required to use regardless of whether there are better choices for their application of their business.

  10. Pingback: Teaching Online Journalism » Tips for HTML5, part 4: New tags

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.