Canvas lets us draw programmatically on a specific area of a web page. And it can do some pretty cool things: design enhancements, visualizations, drawing/painting applications, image manipulation, and games (the visual side, at least).

Later we’ll get into the nuts and bolts of Canvas. But first let’s look at some big-picture stuff and the inevitable comparisons to Flash.

Canvas is not Flash, and comparing a single piece of web technology for (primarily) 2D graphics to a feature-rich, broadly supported client environment and a mature ecosystem of development tools is a bit apples and oranges. Canvas alongside HTML5 (and related) technologies, however, is being touted as a serious Flash competitor. But exploring Canvas (and HTML5 on the whole) made me wish I could do some of the amazing things being done with Flash. This isn’t a popular opinion—I’m writing about web standards, so shouldn’t I hate Flash? It’s also not one I thought I’d have; I haven’t used Flash for a decade, and as a stereotypical designer/Apple fan (tautology?) I regularly experience the memory-hogging, crash-tastic, resource-consuming, pain in the ass that Flash is on the Mac (and apply Flashblock liberally).

And while HTML5 has come a long way, Canvas and WebGL still haven’t replaced Flash. Support for <video> is letting many sites integrate interesting animated backgrounds and the popularity of scroll effects is making them feel more interactive, but for something truly immersive Flash still feels like the only game in town. Don’t believe me? Go to any modern video game or movie site. Nine of out ten of them are still built in, you guessed it, Adobe Flash. That’s not to say things aren’t changing, though, and Adobe themselves have started to build Canvas export features into Flash Professional. We’ll consider some examples and pit these technologies head to head in the rest of the chapter.

Flash Is Dying, and HTML5 Is All We’ve Got

Nevertheless, it’s hard to escape the fact that Flash is dying.

As you know, there’s no Flash on iOS devices, as has been widely discussed. (See the April 2010 piece “Thoughts on Flash” by the late Steve Jobs for why Apple chose not to support Flash: www.apple.com/hotnews/thoughts-on-flash/.)

But there won’t be any Flash plug-in on future Android devices, either. In November 2011, Adobe announced it was discontinuing support for the Flash plug-in on mobile devices altogether (see  http://blogs.adobe.com/conversations/2011/11/flash-focus.html), shifting its focus to Flash-driven native apps through Adobe AIR and, ultimately, HTML5.

Windows Phone has also never supported the Flash plug-in.

The absence of Flash on iOS devices (at a minimum) made offering a mobile, HTML-only version of a site a necessity for most sites. And if you are going to build an HTML version of your site anyway, you need a pretty good reason to build an additional Flash-based desktop site. But the justification could still be made in some cases—a simple HTML site for mobile and a rich Flash site for desktop, perhaps.

Then Microsoft dropped a bombshell.

In September 2011, Microsoft announced that for Windows 8, the nonlegacy version of IE10 would not support any plug-ins (http://blogs.msdn.com/b/b8/archive/2011/09/14/metro-style-browsing-and-plug-in-free-html5.aspx). No Flash, no Silverlight, nothing. Flash for mobile browsers was a nonstarter, but this announcement from Microsoft signaled the beginning of the end of Flash on the desktop, too.

The writing for Flash was on the wall. The default experience of the flagship operating system that will run on hundreds of millions of the world’s desktops wouldn’t support Flash (or any other plug-in technology).

Shortly after making the announcement, Microsoft reversed its decision and decided to keep on supporting Flash, but the damage was done. Like many “dying” and “dead” technologies before it, Flash continues to exist comfortably long after passing from vogue, and a company as large and widespread as Microsoft can’t stop supporting it so quickly. At the same time, Adobe has drastically reduced the size of the Flash development team, moved it all off-shore, and doesn’t seem to be investing resources in extending the platform. Flash, the plug-in, is still dying, though it may be a while before it’s finally dead.

Can Canvas and HTML5 Fill the Gap?

At some point in the future, advanced graphics and audio won’t be delivered through a plug-in like Flash. Already each new year reveals more and more people who connect to the Web primarily or exclusively through post-PC devices such as phones and tablets, where Flash doesn’t exist. Consider the implications:

• Advertising: Site owners and advertisers can’t sit idly by as their ad revenue and click-through rates fall, and they’re not going to go back to animated GIFs. There’s going to be a huge shift to HTML5-powered (and mobile-viewable) banner ads, and Canvas will have a big role to play there.
• Media delivery: Audio and video content will need to be delivered using HTML5, but as we’ll see in the next chapter, that’s not as straightforward as it sounds.
• Games: HTML5 games will also rely heavily on Canvas, as we’ll explore later in this chapter.
• Sites: Finally, there’s going to be a massive number of legacy Flash sites that simply can’t continue to work in their current Flash-powered form. Restaurant sites, I’m looking at you. (There’s a niche in converting Flash-based restaurant sites waiting there for someone!) Sadly, this also means great interactive sites like the Lego Star Wars III site will need to be rebuilt, but ideally this encourages enterprising designers and developers to push web standards to their absolute limits to enable the kind of incredible experiences Flash has been delivering for years to a post-Flash world.

Flash Authoring for HTML5?

For a while, Adobe played with the idea of using its Flash authoring platform as a way to generate HTML5 content. Adobe introduced this idea in 2009, when it demoed such functionality at the MAX conference (see the demo at http://youtu.be/v69S22ZBBqA), and again in early 2012 with an announcement of an extension Adobe was working on called “The Adobe Flash Professional Toolkit for CreateJS” (see the announcement and a video of it in action here: http://blogs.adobe.com/creativelayer/html5-flash-professional/). (Erroneous reports made the rounds in mid-2010 that Flash CS5 would export to Canvas, based on the MAX 2009 video resurfacing, but that was not the case.) The latest demo shows a simple animation making the jump from Flash to Canvas and playing smoothly on a PC and iPad, but whether this tool will be sophisticated enough for most web professionals (when it’s eventually released) remains to be seen.

Just a year later, however, Flash as an HTML5 IDE started looking less and less like a real part of Adobe’s plans. In 2010 Adobe also released an experimental FLA-to-HTML tool called Wallaby [http://labs.adobe.com/technologies/wallaby/] that relies heavily on SVG and WebKit-only CSS3. Wallaby was then rolled into a new JavaScript creation platform called “CreateJS”, sold as a “suite of JavaScript libraries and tools for building rich, interactive experiences in HTML5”, which Adobe still supports and promotes at the time of this writing (http://www.createjs.com/).

Then in 2011 Adobe released a preview of new product they were calling “Edge” (http://labs.adobe.com/technologies/edge/), a simple HTML animation tool that relied mostly on JavaScript, despite “HTML5” claims. It allowed users to make complex animations and tweens, similar to those from Flash, but using 100% “open web” technology. At the time of this writing, Edge is now a full product line from lAdobe, and includes things such as an animation application (the original “Edge”, now Edge Animate, and still no Canvas support), a coding environment,  a design tool (Reflow), typography tools, and PhoneGap, which Adobe acquired in October 2011.

At the time of this writing, Adobe have just announced an update to their Flash Professional CC line, which adds support for exporting animations to Canvas. This is a big step, and something that has stirred up quite a bit of interest. Could this be the Canvas animation tool that designers and developers have been clamoring for? At this point, we’ll just have to wait and see.

And Then Apps Happened

Because of the immaturity of some important HTML5 features (especially audio and video, as we’ll see in the next chapter) and the lack of mature design tools for things such as Canvas, some site owners may have no choice but to stick with Flash over the next few years, especially as a legacy technology. Or, they’ll start pushing apps.

We’re entering a strange period for the Web.

On the one hand, as far as technology goes, web standards have won, and won handsomely. They have persevered in the face of numerous challenges from proprietary technology (Flash, Silverlight, and many others that have fallen by the wayside), implementer apathy (for example, Microsoft letting IE stagnate in the ’00s), and specification dead ends (the W3C’s XHTML 2 debacle). For web purists, this is an incredible victory that seemed anything but certain several years ago. After all, Microsoft—Microsoft!— tried releasing a desktop version of its browser that only supported web standards and has not only joined the party in implementing cutting-edge web technology but is doing it particularly well.

On the other hand, the web standards we’ve got with HTML5, and the associated development tools, are still not very good. Canvas, as we’ll see, has its uses, but Canvas, and HTML5 in the broadest sense, still has a long way to go in development, adoption, and tool set before it can rival what can be done with Flash today. So, what will happen when developers want to do something cool but they can’t do it in the browser?

They’ll create apps.

iOS apps. Android apps. Windows apps. Mac apps. Platform-specific apps that, ironically, take us away from the true promise of the Web—that it’s available to all, from any platform. We saw an explosion in platform-specific software in the ’90s as desktop PCs became common, and then web apps started to emerge in the ’00s—software that was liberated from any specific platform vendor. Now we have a fierce competitive environment where major platform vendors (that is, Apple, Google, and Microsoft) see having the best apps as a competitive advantage, and two of those vendors are doing their bit to “sunset” Flash as a relevant web technology platform.

This leaves us in the curious situation where there is an exploding market for apps and a rapidly maturing web standards environment but some gaping holes in the web technology platform that gets broadly labeled as “HTML5.”

It’s an interesting time for the Web—web standards won but so far without the technology for the Web to go all the way as a ubiquitous platform for all. We’ve instead seen a ’90s-esque explosion of platform-specific apps and the threat that vendor-specific “walled gardens” will make the Web a second-class citizen.

All is not lost, though. For one, many of those “native” apps are powered in large part by web standards under the surface. And Adobe, for its part, is also investing in HTML5 development tools and getting involved in the web standards process. The browser makers are improving their browsers at a breakneck speed, and new specifications to bridge the gulf between web standards and native app development are appearing all the time. We’ll explore this more in Chapter 12 when we look at HTML5 and web apps.

Let’s Bury Flash-isms with Flash

If Flash is dying on the Web, we should aim to bury some Flash-isms with it. Let’s make sure we remember the lessons of the Flash era, especially when it comes to splash pages, loading screens, pointless animation, annoying widgets, and over-engineered, over-designed “experiences.” They were mostly terrible ideas. Some things simply don’t bear repeating, whether it’s done in Flash, mountains of JavaScript, advanced CSS3, Canvas, or some ungodly combination of these technologies.

Let’s also be careful of judging a technology too quickly. Canvas is going through its awkward adolescence at the moment—full of potential, embarrassing mistakes, experimentation, monosyllabic grunts, and finally (ideally!) maturity. Whenever new technology enters the web scene, it’s generally shown off in a bunch of experimental or inappropriate ways as a gimmick before settling into its groove and being used moderately and appropriately. I hope Canvas finds its groove quickly.

We’re Not in Canvas Anymore

That’s the background. Now let’s look at what the Canvas element actually does.

The <canvas> element defines a bitmap area—or “canvas,” if you will—that you can program and draw on with Canvas’ JavaScript API. The Canvas element has been kicking around since 2004 and was rolled into HTML5. All modern browsers support it natively (including IE9, although IE6–8 need to use emulation), as do modern mobile browsers.

The actual element looks like this:

<canvas id="mycanvas" width="500" height="200">
   Sorry, your browser doesn’t support canvas.
</canvas>

Like other things in HTML5, browsers that don’t understand <canvas> tags just see them as a generic element (like <mymadeupelement>) and ignore them, exposing the text between them.

That’s it as far as the HTML goes. Everything else happens through the JavaScript API, which lets us do the following:

• Draw shapes, gradients, and shadows
• Manipulate images and text
• Create animations (by redrawing the canvas enough times per second)

Working with Canvas is like drawing on a single layer in Photoshop. You have only one layer of pixels to work with, and once you draw over them, they’re gone. So, to do animation (in games, for instance), we need to redraw the canvas for every frame. Canvas has no sense of managing and manipulating objects (that’s more SVG’s thing, which we’ll look at in Chapter 11), but a variety of libraries (for visualizations and games, in particular) have sprung up to help deal with this.

Given Canvas is manipulated through its JavaScript API, the extent you’ll want to get your hands dirty will depend on your interest in JavaScript and drawing graphics programmatically. Here’s an example of how we would draw a basic square (using the earlier <canvas> element and <body onload="draw();">):

function draw() {
   var canvas = document.getElementById('mycanvas'),
   var context = canvas.getContext('2d'),
   context.fillStyle = "rgb(200,0,0)";
   context.fillRect (10, 10, 100, 100);
}

This function gets our mycanvas Canvas element (using the 500 x 200px example we looked at earlier), sets the fill color to red, and then draws a solid red rectangle using the fillRect(x, y, width, height) function. As you can see in Figure 9-1, we’ve drawn a red square that is offset 10px on the x-axis, is offset 10px on the y-axis, and is 100px wide and 100px high. (I’ve added a 1px border around our <canvas> with CSS so you can see the size of the element itself.)

We won’t delve into the workings of the Canvas API because there’s plenty of solid resources online, including the following:

• Mozilla’s Developer Network Canvas tutorial is a great place to start because it covers the basics and has a bunch of links in each section to other resources: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Canvas_tutorial
• Opera has a short introduction to the basics of Canvas here: http://dev.opera.com/articles/view/html-5-canvas-the-basics/.
• Mark Pilgrim’s Dive Into HTML5 has a lengthy chapter on getting started with Canvas: http://diveintohtml5.info/canvas.html.
• There’s a tutorial for creating a breakout clone with Canvas here: http://billmill.org/static/canvastutorial/.
• There’s a whole site dedicated to Canvas tutorials here: www.html5canvastutorials.com/.
• The HTML5 spec for web developers (without all the implementer detail for browser vendors) has a concise run-through of Canvas’s features here: http://developers.whatwg.org/the-canvas-element.html.

Canvas has great potential for gaming and visualizations, along with more mundane uses such as creating charts and even tooltips. But perhaps the most exciting use for Canvas is bringing 3D to the web in a roundabout way with WebGL.

We’ll look at that in a moment. First, let’s look at some examples of Canvas in action.

Cool Things with Canvas

You can do a bunch of cool things with Canvas, from animations to full-blown games. Let’s start with something a bit more modest, though: tooltips.

The Haphazard World of Web Standards (Or: How Did We End Up with Canvas?)

Let’s touch on the history of Canvas because it illustrates how haphazardly these features can be developed (as was the case with much of HTML5, which is in some ways just a grab-bag of tech that’s been around for years).

—Dave Balmer, www.slideshare.net/dbalmer/rockstar-graphics-with-html5-media-uk

Do you use OS X’s Dashboard feature? That’s where Canvas originated, back in 2004. Apple wanted Dashboard widgets to be easy to write, so it based them on the good ol’ web stack of HTML, CSS, and JavaScript (and native code if you wanted) and used WebKit to render them. (WebKit is the rendering engine behind Safari and Google’s Chrome.)

But Apple thought the web stack for rendering Dashboard widgets had limitations, so it added a few features to WebKit, the major one being Canvas. Safari uses WebKit, and so Safari now supported Canvas. And lo, Canvas on the Web was born.

This, in the tradition of new web technology, caused considerable concern.

Vendors adding browser-specific features to HTML, without any standards process, is what the web standards movement was trying to get away from. Had Microsoft and Mozilla responded with their own, incompatible attempts at something like Canvas, we would have a great mess on our hands.

So, Ian Hickson reverse engineered Apple’s Canvas implementation and put it in the WHATWG Web Applications 1.0 spec. Canvas gained support in Firefox 1.5 in 2005, Opera 9 in 2006, and finally IE9 in 2011. The WHATWG Web Apps 1.0 spec became HTML5 as we saw in Chapter 1, and Canvas is now an official part of HTML5. Hats off to Hickson for all his work bringing it into the spec.

(For more on Canvas’ history, see http://peter.sh/2010/06/thank-you-microsoft-html5-canvas-is-a-go/.)

The Canvas Element and Accessibility

In terms of accessibility, Canvas can be a bit of a nightmare. There’s nothing for a screen reader to read—just a black hole and whatever text (if any) the designer has put between the <canvas> tags.

Vendors are trying to address this. For example, IE9+ exposes the fallback content between the <canvas> tags to assistive technology. The idea here is that when the browser does support Canvas but the vision-impaired user can’t see it, they can still get something useful in the form of alternate text via their screen reader, for example. (Well, that’s the theory. At the moment they’ll get a lot of erroneous “Your browser doesn’t support canvas” messages, because that’s how the fallback content has been used to date.) For more, see accessibility guru Steve Faulkner’s discussion of this feature at www.paciellogroup.com/blog/2010/09/html5-canvas-accessibility-in-internet-explorer-9/ and the right way to make content inside of a canvas accessible at http://blog.paciellogroup.com/2012/06/html5-canvas-accessibility-in-firefox-13/.

As for the accessibility of the Canvas element itself, it’s a thorny issue that has been discussed for years, and it still hasn’t been resolved. There’s a summary of the last few years of discussions at www.paciellogroup.com/blog/2011/12/html5-canvas-accessibility-discussions-2009-2011/, but that’s as far as we’ve come.

Let’s not repeat the accessibility mistakes of decades past with <canvas>. We could in theory render fancy text, an entire web page, or a web application (which has been done!), with JavaScript in a <canvas> area. But it’s a terrible idea and about as useful (from an accessibility perspective) as having our design as one giant image.

(You can do some crazy things with text in Canvas, though, as this tutorial illustrates: www.html5rocks.com/tutorials/canvas/texteffects/. So, we may still do text replacement with such techniques.)

The Current State of Canvas

Technologies (web or otherwise) don’t exist in a vacuum. Their success often depends on having a conducive environment around them. There’s certainly plenty of enthusiasm for Canvas, but what about the environment around it?

HTML5 Gaming: Canvas or Not?

Canvas often gets mentioned when discussing HTML5 and games, so let’s take a brief look at the state of HTML5 gaming. Could you use your existing web skills to write games using HTML and JavaScript that run in any modern browser? Sure, if you’re comfortable developing in JavaScript. Will the game be any good? Well, that depends....

One of the biggest trends in recent years has been casual gaming, both in browsers and on mobile devices such as the iPhone. From FarmVille to AngryBirds to CandyCrush, social games on the web (primarily inside of other services like Facebook) or mobile devices have been a dominant force in the gaming world for recent years and keeps growing as smart phone penetration grows.

So, an open, cross-device platform for creating casual, social games is appealing, from both a hard-nosed business perspective and an idealistic “open platform” perspective, and HTML5 fits the bill quite nicely.

The key is to understand what type of “gaming” we’re talking about here. Graphically these are often simple 2D games, similar to what was around in the early ’90s. In this sense, it’s very much “back to the future”—we’re using the latest web tech to create games that look 20 years old in the very modern, mobile world of social networking.

Getting Started with Canvas Game Development

Nevertheless, if you want to get hands-on with Canvas for gaming, check out the tutorial and overview (just ignore the hype in the article) at www.html5rocks.com/tutorials/casestudies/onslaught.html or the absolute beginners tutorial at www.lostdecadegames.com/how-to-make-a-simple-html5-canvas-game/. And don’t forget the game examples we looked at earlier, including Cut the Rope (www.cuttherope.ie).

For a detailed rundown of all the different technologies available for “HTML5” games (in the broader sense) and their delivery and monetization options, check out this excellent article from January 2012: “The Reality of HTML5 Game Development and making money from it” (www.photonstorm.com/archives/2759/the-reality-of-html5-game-development-and-making-money-from-it). For a more up-to-date listing of popular HTML5 games, check out html5games.com.

Canvas: What’s in It for Me?

Now that we’ve looked at some specific use cases for Canvas on the web, let’s consider canvas from a different perspective: what type of people is it relevant to?

2D Canvas’s 3D Future: WebGL

I’ve left the best to last—one of the most exciting developments related to Canvas is WebGL (Web-based Graphics Library). Despite Canvas’s ostensibly 2D origins, the new WebGL standard gives Canvas a hardware-accelerated 3D context powered by OpenGL—if the browser (and underlying hardware) supports it. This opens the door to modern, 3D gaming in your browser.

(The WebGL spec wasn’t developed by the W3C or the WHATWG but instead by nonprofit technology consortium Khronos Group, which sprang from Mozilla and shepards OpenGL as well. So, it’s not HTML5 per se, but it’s still cool.)

The WebGL working group includes Apple, Google, Mozilla, and Opera. (See the Wikipedia entry for more: http://en.wikipedia.org/wiki/WebGL.) Microsoft was a late adopter of WebGL, citing some legitimate concerns around security that were echoed by others (such as John Carmack, founder of id Software and a highly respected gaming developer: https://twitter.com/#!/ID_AA_Carmack/status/81732190949486592). But with Microsoft on board in IE11, it’s looking very likely that WebGL will be the de facto hardware-accelerated 3D content technology provider for the modern Web.

(Here’s a techcrunch blog post on Microsoft’s adoption of WebGL: http://techcrunch.com/2013/10/21/with-internet-explorer-on-board-webgl-is-ready-for-prime-time/.)

3D on the Web: WebGL Alternatives

WebGL isn’t the only game in town, either.

The major players in browser technology were eyeing 3D development years ago. Adobe Flash had a thriving 3D development community years before it introduced hardware accelerated 3D in 2010. Around the same time, Microsoft introduced hardware accelerated 3D in its Silverlight plugin. But with Silverlight all but gone as a browser plugin and Flash quickly disappearing, what options do 3D developers still have?

Interestingly, Unity Technologies, which makes the popular cross-platform (and very mobile-friendly) 3D engine Unity, has been distributing its own browser plug-in, which it claims has seen 225 million downloads. It is also rolling out an export-to-Flash option so users don’t need to download the Unity browser plug-in. Microsoft also recently announced a deal with Unitey for creating content for Windows 8 devices, dedicating “porting labs” to help developers, and claims at least 1000 game ports to date (see their announcement here: http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/11/18/1000-unity-apps-across-windows-store-and-windows-phone.aspx).

It’s worth noting that Unity’s made a lot of headway into all of the areas Flash was tryin to get to extend it’s life: games, 3D, and exporting directly to mobile devices. More than Canvas, WebGL, or any other HTML5 technology, Unity may be the player that actually replaces Flash in those contexts.

WebGL also has old-school predecessors. Displaying 3D on the Web isn’t new—Virtual Reality Modeling Language (VRML), for example, dates back to 1994 (see http://en.wikipedia.org/wiki/VRML). But with hardware-accelerated 3D now pretty much a given on any platform (including smartphones), the potential for 3D on the Web for gaming and beyond (for example, 3D-modeled product previews, medical models, maps, and more) is infinitely greater.

Who knows? Maybe we’ll finally have the technology for that 3D “virtual” shopping mall experience we’ve all been, uh, craving...

So WebGL isn’t the only game in town, but support and popularity are growing fast. Let’s look at a few demos and you can make up your own mind about whether you think plugins are a part of the 3D-and-gaming web’s future or not.

Show Me the Demos!

When it comes to WebGL, seeing is believing. So, fire up the latest version of your favorite browser and check out these cool demos. And remember, this is all happening in <canvas>—just another element in the DOM (which we can push around with CSS3).

Epic Citadel

In 2013 Epic Games released a demo of the Unreal Engine 3 running in WebGL (Figure 9-25). The company released a small level called the “Epic Citadel” that allowed a player to navigate an immersive, if small, 3D world. It demonstrated that WebGL could be used to deliver console-quality experiences in the browser. Check it out here: http://www.unrealengine.com/html5/.

Still Early Days for WebGL

The WebGL games and demos show incredible promise, but it’s not all beer and Skittles for WebGL development at present. One developer on Hacker News commented on the hardware incompatibilities, software bugs, and inconsistencies that can make it a difficult development environment for small teams, saying this (https://news.ycombinator.com/item?id=3253016):

Nevertheless, as the earlier demos show, amazing things are possible. And if you’re interested in the raw performance details of WebGL, check out the extensive post “HTML5 2D gaming performance analysis” (www.scirra.com/blog/58/html5-2d-gaming-performance-analysis) from Scirra, developers of HTML5 game–making tool Construct 2, which concludes the following:

WebGL’s also made inroads in mobile browsers, gaining support in the mobile versions of Firefox, Opera, Chrome (if enabled), and IE (with a polyfill.) At the time of this writing mobile Safari is the only holdout and Apple hasn’t announced any plans to make it available.

That wraps up our discussion of Canvas, Gaming, and the future of immersive experiences without Flash. Next we’ll dive into the exciting and misleading world of HTML5 Audio and Video support.