Easily build powerful user management, authentication, and authorization into your web and mobile applications. Download this Forrester report on the new landscape of Customer Identity and Access Management, brought to you in partnership with Stormpath.
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?
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 simonsarris.com
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
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
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
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
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?
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 (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
The Web Dev Zone is brought to you by Stormpath—offering a complete, pre-built User Management API for building web and mobile applications, and APIs. Download our new whitepaper: "Build Versus Buy: Customer Identity Management for Web and Mobile Applications".