The Canvas element is one of the most exciting and celebrated new technologies that arrived with the new HTML5 specifications. It gave web developers and designers the ability to create many dynamic graphics that they were previously only able to make with plugins like Flash. Because of technologies like Canvas, the Web has taken center stage instead of proprietary technologies. It was only fitting that DZone should produce its first follow up to the wildly popular HTML5 Refcard with an HTML5 Canvas Refcard. For that task, DZone asked Simon Sarris to author the Refcard. Simon is a Canvas specialist and if you look for the top users for the "canvas" tag on Stack Overflow, you'll find him at the top. He's answered nearly 10% of all canvas questions on Stack Overflow. So here's your chance to meet the Canvas guru, Simon Sarris.
DZone: Could you introduce yourself please?
DZone: What's your summarized understanding of where/how the HTML5 Canvas Element began and how it's evolved up until this point?
: I'm a software developer from New Hampshire. These past two years I've engrossed myself in the finer points of the HTML5 Canvas Element. I spend a fair amount of time helping others with Canvas, from getting apps started to solving complex issues. Much of my help is done through StackOverflow, where I've answered nearly 10% of all Canvas questions ever asked. I also blog a few tutorials on common issues at
Sarris: Apple originally created Canvas and inserted it into WebKit back in 2004 to fulfill a few UI needs, namely so they could draw arbitrary content for OSX Dashboard widgets and well, anywhere on the web while they're at it. WebKit is the rendering engine behind Safrai and Chrome, and the HTML tag was adopted relatively quickly by most other browsers in the coming years, though the performance and completeness of the implementations weren't widely usable until around 2009 or so. In 2011 IE picked up Canvas and all the major desktop browsers have now implemented some kind of hardware acceleration.
DZone: In the card you describe the differences between SVG and Canvas. What types of problems that were previously solved with Flash, should developers now turn to SVG or Canvas?
This has caused Canvas to go from a very neat toy to a serious contender for replacing Flash, Silverlight, and related rich-web plugins.
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.
DZone: Is there anything important as far as tips, tools, or best practices that developers should be aware of when developing a Canvas that needs to work well on a mobile device?
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.
DZone: What additonal resources would you recommend to supplement the reading of your Refcard?
Sarris: The Mozilla 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.