HTML5 Canvas Refcard - Meet the Author: Simon Sarris

Sarris: Flash became very popular relatively quickly because it was one of the few ways to display video in the browser, particularly notably in 1996 when the MSN and Disney websites adopted it. In the early 2000's thousands of websites were using Flash as developers began making more and more elaborate games and animations, and also all kinds of nauseating website navigations that thankfully fell out of style. Back then there was no native way to do these things. Today it's a different story, and all of these things are quite possible natively with Canvas and SVG.

Mobile developers should all have their eyes on Canvas, because Flash and other plugins are not (and may not ever be) supported on some mobile browsers. Depending on the platform you're targeting you'll want to find an up-to-date compability table to see what technologies you'll need to use to reach all the platforms you want, but in general Canvas apps will be able to reach the greatest number of modern devices in the near future.

Even where Flash is capable on mobile devices, Canvas apps ought to generally be smaller in download size and consume less battery life, merely on account of there being less overhead in the platform.

Canvas and SVG are also more future-proof. Flash is a proprietary platform and therefore has a much less-knowable shelf life. Adobe could end development of Flash tomorrow. Chrome could stop bundling Flash by default tomorrow. The HTML DOM elements Canvas and SVG that replace Flash are far more of a "given", so to speak, when it comes to what future browsers will implement or not.

Sarris: A lot of people ask me how to make a full-screen canvas app work well on mobile devices when they all have varying screen sizes. The solution is to separate your canvas coordinates from what are sometimes called "model" coordinates. There's a bit of nuance, but I'll explain it very informally here:

Say you want to target devices that have the screen sizes 960x640 and 800x480 and say you want to keep the same aspect ratio. The two aspect ratios of those screens are 1.5 and 1.66 respectively and we'll want to cater to the smaller one so nothing is clipped.

When you write the app you'll want to write it in model coordinates which can be anything so long as they have a 1.5 aspect ratio. So you could for example internally use the size 480x320. That is, you'd assume that the height of the app is always 480 and the width is always 320, regardless of what device you're on. Internally you never worry about any coordinates but these, and all of your drawing and logic assume that these are the only coordinates that exist.

Then, when it comes time to draw, you scale your model coordinates to fit the real screen of the app. If the device is 960x480 then you'd call "context.scale(2, 2);" before drawing anything. If the screen size was 800x480 you'd scale by (1.66, 1.66) instead. Mouse/touch coordinates are treated in the opposite way. When you get (x,y) input from the 960x480 device you will want to multiply those input coordinates (1/2, 1/2) to scale them from screen into model coordinates.

So all of the code internally just uses one set of coordinates. The only part of the code that caters to specific devices is how to scale before drawing to the screen and how to scale the input coordinates that come in from  the screen. Of course, every app's needs are different and its sometimes not so simple, but for many projects this works well assuming your model coordinates as large (or larger) than the largest screen, so that all the drawing is scaled down.

DZone: Is there anything you'd like to see changed or improved upon in the Canvas part of the HTML5 spec?

Sarris: Three things come to mind. I think a lot of developers are frustrated that the TextMetrics object only contains a width attribute and not a height attribute. Perhaps more importantly, it is currently possible to reset any part of the canvas context state without modifying the rest of it with the sole exception of the clipping region. There is no way to reset the clipping region without restoring older state or resetting the entire Canvas context state. It's not the end of the world, but it would be beneficial in high-performance apps that have to use clipping. The last improvement would be a way to render arbitrary HTML elements onto the canvas, which would make it easier for some things, such as blocks of text, to more closely resemble "normal" in the canvas. This is especially so because there is no multiline support in canvas and computing proper line-height must be done manually.

Sarris: The Mozilla tutorial (https://developer.mozilla.org/en/Canvas_tutorial) is probably the best short guide to get you up to speed. There are a few books out, but they're an awful lot longer than they need to be when it comes to the fundamental parts of Canvas. The O'Reilly book on Canvas is good you want to learn the basics of making games and multimedia apps.