Tag Archives: webstandards

A quick introduction to the HTML5 Canvas

The next article in the Developing with HTML5 series. Better late than never, but much has happened. Perhaps more on that someday…

A painter paints his pictures on canvas. But musicians paint their pictures on silence. We provide the music, and you provide the silence.

—Leopold Stokowski

HTML5’s canvas element allows us to create and display images on-the-fly using JavaScript. Canvas graphics can often yield speedy performance, particularly on mobile devices and desktops that feature browsers with hardware acceleration enabled. While SVG (which I covered earlier) does feature a convenient model for markup and CSS access to the graphic in question, Canvas can usually do a better job at performance thanks to hardware acceleration and not having to traverse the DOM.

Let’s analyze a basic canvas. Start with a new HTML5 document containing a canvas element in the body:

Save your file. Not much will happen yet, unless you have web browser that doesn’t support canvas. Modern browsers will probably yield a blank white page for the above code. An older non-supporting browser, a text-only browser such as Lynx, or a screen reader will deliver the default text:

Lynx renders default text for canvas

You can draw on the canvas using JavaScript. Place this code above the closing element to try it out:

Now when we preview our page in a supporting browser, we should see a green box:

Green canvas box

To explain what we did with this JavaScript: We wrote a function called draw(), which first uses the d ocument.getElementById() method to grab our #example canvas element. The next line sets the rendering context with canvas.getContext(). We then use the fillStyle() method to assign a CSS color value and the fillRect() method to draw the box.

The prototype for fillRect() is fillRect(x, y, width, height). The x and y values position the box relative to the bounds of the canvas, and the
box is drawn from there using width and height.

Now let’s try a circle. (And throw in some alpha transparency for good measure.) Add five more lines to our ctx variable as shown:

The result should be an overlapping circle

Progress of canvas showing circle overlapping rectangle

Here, we’ve used the fillStyle() element to define a light violet color for our circle. You’ll notice that this time we are passing in one extra number to fillStyle(). That extra number is a parameter that sets the alpha transparency—any decimal value from 0 to 1 is valid, with 0 being fully transparent and 1 being fully opaque.

In this case, our value of 0.5 might be thought of as a 50% transparency. We see the true violet color of our circle along the right edge where it hangs off of our green square, and we see a blend of the two colors (which happens to be a neutral gray) where the two shapes overlap.

Because we want to create a circle instead of a square in this example, we need to use the beginPath() and closePath() methods to draw a linear shape. We use the arc() method for defining the path itself. The first two values in the arc() arguments are x and y coordinates within the canvas. Third is the arc radius, which here is set to 75 pixels. The last two values are the start angle and end angle. We can specify a calculation for these angles, so here we set our end angle by leveraging JavaScript’s built-in Math object to multiply pi by 2.

Now let’s add a regular jpeg image to our canvas after our circle (below the last ctx.fill() line):

piano keys closeupThis adds our piano image (shown here—please feel free to download for use with this tutorial) to the canvas. Above, we begin by initializing a new instance of the Image object. The src property specifies the path to our image (which may be relative or absolute). Next, the onload property tells the canvas to execute the drawImage() method, specifying our piano image as the source and x and y coordinates of 30 pixels each.

But why is that special? After all, we could have just inserted an <img> tag there, right? Yeah, but since this is JavaScript, we can clone it. Here’s how to add another instance of the image using different parameters:

We’ve resized our cloned image, too. (It’s now 70 pixels square.) And now we can apply effects to it. How about trying a little drop shadow?

Here’s our finished masterpiece:

A rectangle, circle and two copies of a piano keyboard image composed onto the HTML5 canvas

And that is what modern art is all about. Here’s our final code example:

This is just the tip of the iceberg—but it should be enough to show how to get a basic canvas working in HTML5.

The canvas element is fairly well supported on modern versions of most web browsers, including Firefox, Safari, Chrome, and Opera. This goes as well for their mobile equivalents, with the exception that the Text API for canvas has spotty support for Opera Mini.

Internet Explorer 9 even includes support for the canvas element. For older versions of IE, add Explorercanvas as a source to your web page and you’ll achieve pretty good compatibility out of the box. You can check current browser support for canvas features on caniuse.com

SVG and MathML in HTML5

The next article in the Developing with HTML5 series.

Pick a flower on Earth and you move the farthest star.

—Paul Dirac

Scalable Vector Graphics (SVG) and MathML are XML applications that are widely used in scientific contexts. SVG is used to draw vector graphics, and is frequently found in visualization libraries such as ProtoVis. MathML is used to describe the presentation and meaning of mathematical formulæ. They are very easy to work with in a programmatic sense, because they are XML-based and therefore just text, and yet they are capable of rendering beautiful information in supporting web browsers.

Paul Dirac, who loved the maths.
Paul Dirac, who loved the maths.

The idea behind XHTML was to move the web toward extensibility (the X in XHTML), where a web browser markup language could be seeded with bits of other XML applications by declaring a namespace and letting things coexist. The problem with that plan was that XML parsers were required to be extremely fussy, to the point that if a problem was detected the browser should render an error message. Browsers don’t work that way. Instead, they forgive your human or computer errors and render the page as best as their little hearts can.

In the beginning of the process, HTML5 was not extensible, and to this day it remains opposed to the whole namespace idea. But SVG and MathML are highly popular and useful XML applications that deserve a place within the HTML5 spec. And so shall it be: <svg> and <math> are the opening volleys in inserting SVG and MathML into your HTML5 document tree. Any elements that are children of the SVG and MathML specs are valid and functional child elements of the <svg> and <math> elements respectively. No need to declare a namespace. You’re done. Thank you.

Now this is not to say that the idea of inserting these XML applications within the HTML5 spec is not without some controversy. What about other XML applications and XHTML extensions such as RDFa, CML, and MML? CML (Chemical Markup Language) and MML (Music Markup Language) are indeed common, but within specific application contexts. They are not supported yet by any web browser (whereas MathML and SVG are well supported.) RDFa on the other hand is a more political issue: More on that whole mess in a later post… 😉

So in short, SVG and MathML are supported objects within HTML5 because they are widely deployed in existing web browsers, and they are very useful – particularly to those of us in the science industry charged with representing scientific information on the web. Let’s look at how to get started. First, an SVG example – simply start your SVG block using the <svg> element and drop your SVG markup within:

Here’s a live example that will work in browsers that support SVG and MathML in HTML5. (Try it in the Firefox 4 beta.) Or if you aren’t one of those early-adopting browser users that are used to living dangerously, then please refer to the perfectly safe reference image below:

Reference rendering of the sun in SVG.
Reference rendering of the sun in SVG.

To learn more about SVG, check out the w3schools SVG tutorial for starters. While SVG is supported in basic forms in Chrome, Safari, and Firefox, only Firefox 4 (currently in beta) supports embedding SVG natively in HTML5. But Chrome will follow soon, followed by IE9, Safari, and eventually (hopefully) Opera.

MathML is equally straightforward, using the <math> element as the opener:

Compare to the reference rendering below, or check out the live example.

The Dirac delta function rendered from MathML in Firefox 4 beta
The Dirac delta function rendered from MathML in Firefox 4 beta

Again, currently Firefox 4 beta is the only close-to-shipping browser that supports this. But it is expected to come to all major modern browsers in 2010/2011, including IE9, Safari, Opera, and Google Chrome. To learn more about how to construct MathML, check out Mathematica’s MathML tutorial.

In short, it’s an easy trip to embed SVG and MathML in HTML5. No namespaces are required. The trade-off is less extensibility, but if you need extensibility back there’s an XML flavor of HTML5, appropriately titled XHTML5. In the meantime, start looking for ways to leverage SVG and MathML in the coming months as capable browsers start coming online! While this is indeed a bit on the bleeding-edge side of things, web browsers are beginning to implement these features and I expect over the next year or two the practice of embedding SVG and MathML markup in HTML5 web pages will become entirely commonplace within the scientific community.

First steps with HTML5

As I mentioned in my earlier post, HTML5 means quite a lot more than what we all understood markup to be in the HTML 4/XHTML days. At the core of the HTML5 specification however, markup is still the foundation. Let’s take a quick look at some of the differences between HTML5 and it’s predecessors. But before we get too into this HTML5 series, I should mention that the principal reason I’m posting my thoughts here on the subject is to learn for myself, and secondly to document a nugget of information or two that might be useful to you all out there. Excellent stuff has been written on this subject. Go read Bruce Lawson and Remy Sharp’s book Introducing HTML5, Mark Pilgrim’s HTML5 Up and Running, and Tantek Çelic’s HTML5 Now. Go read every one of these books cover to cover — I highly recommend them.

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

—Albert Einstein

Einstein and Tagore, Berin, 1930
Physicists with mad hair who most assuredly would have been totally down with HTML5.

I will now go through some of the reasoning akin to the way Pilgrim and Lawson follow in constructing the optimal basic HTML5 markup template, with my own commentary, flavor, and style thrown in just so I can acquire it in my head and hopefully help you all along with the reasoning:

The first line of code we see in HTML documents is the doctype. The reason why it is standard practice to use doctypes in markup, as all good web developers already know, is to trigger standards mode in web browsers. All major modern web browsers support this function, and it makes the role of a web developer much simpler to develop a consistent user experience across all platforms. If you’re familiar with the doctypes of HTML 4 and XHTML 1, you are familiar with how complex they appear.

Not the type of thing one would readily commit to memory at first glance. The HTML5 doctype is significantly shorter:

There – fixed it.

With just a little experimentation, it was found that all browsers triggered standards mode with just the above minimal amount of code. So the HTML5 spec was written to codify what was already in existence, in the most compact and simplistic way that works. No long URL. No unmemorable string of voodoo or versioning cluster nonsense. Just the standards mode, please. That’s all we need – something simple and to the point.

The next thing you should know about is defining a character set for your document. This is a departure from the straightforwardness of our journey into HTML5 markup, but it is important for addressing a security concern where browsers attempt to guess character encodings that could conceal malicious scripts, so let’s get off on the right foot shall we? First, the old way:

Again, not the most memorable code. But then, that’s why I like HTML5: It fixes things. This is much better:

I should also point out something important here. In HTML5, you don’t need to place quotation marks around attribute values if there are no spaces. Spaces separate multiple values, and you need those quotes to herd them together and distinguish them from standalone attributes (which we’ll get into later). So, this would also be perfectly valid:

If you’re compressing a document for speedy delivery over slow networks, such as mobile contexts, then here’s a place to save a few bytes. But in general, it’s my personal preference to quote my attribute values for legibility’s sake.

Another thing you might notice is that this standalone element is not self-closing in the XML sense. You could write it that way, as in:

That’s with the trailing slash before the end closing angle bracket, in case you missed it. This would be the way it would be done were our document conforming to XHTML rules. XHTML5 is the XML-conformant variant of HTML5 and is developed as an option to the HTML5 specification. But it is not necessary, unless you really need XML parsing to be enabled. And the good news is, HTML5 allows for SVG and MathML embedding without having to switch to XHTML mode, so for most contexts even at the scientific level, we won’t need the X tacked on to the front of our HTML5. But please, don’t let that stop you from self-closing those tags. I myself only recently got out of the habit, after writing HTML5 for the past 10 months or so. It’s perfectly valid either way.

The rest of your basic HTML5 document at this point will look very familiar, with just a few things to point out. The most notable difference will be the opening HTML tag. Usually we’d just open up our markup tree with this:

However, if we were pulling out all the XML stops and such, we would be defining a namespace and a language, as so:

In HTML5, it is certainly not necessary to define a namespace (the xmlns part) because that much is assumed. That leaves us with the language declaration, in the form of the lang attribute. Lang attributes are specified according to IETF BCP47, and there’s a practical list of these codes that may be used on MSDN. A lang attribute is used by search engines to understand the content meaning better and categorize the results. It is used by speech synthesizers to produce the correct pronunciation of words with similar spellings across languages. It is used by browsers for producing the correct hyphenation, spelling correction, and so on, even across regional dialects. A lang attribute specifies the language of the contents of the given element, which means you may specify several languages on a given document.

Do use the lang attribute. Even better – use it regionally. I would specify lang=”en-us” (English – U.S.) for most of my web work, but on occasion I’ll dip into Traditional Chinese for my language studies, with specific vocabulary rules for Taiwan, in which case I’d use lang=”zh-tw” (Chinese, or “zhongwen” – Taiwan).

I’m fascinated by language processing and character sets in computing, so forgive my overly-thorough description of the situation back there. The point is, in HTML5, we can shorten this information on the opening HTML element to this by removing the namespace and the xml:lang attributes, and including the addition of my regional preference:

There, that’s a gooood HTML element. For other elements in your document, such as perhaps LI or P, you might specify additional languages as needed.

Bruce Lawson has a nice, clear writeup of what he considers to be the minimal HTML5 document framework. I agree with this markup template, with my own minor stylistic modifications presented below:

The rest is pretty straightforward, right? We have the overall wrapping HTML element, a HEAD, a BODY, our charset definition, our lang attribute set to Amurikun, well-formed tag organization, a title attribute, and some content. That’s it – not too different from our past experiences with HTML4 and XHTML, but arguably much simpler. You now can fill in the rest of your markup as needed as if it were HTML 4.01, and it’ll work in all modern browsers. That’s right, it’s OK to get started with this much right away. But if we stopped there, that would be missing the point of the new semantic conveniences of HTML5! So in the next post we will explore those constructs in a little more detail and talk about how these new constructs will save you time and make more sense for web development in the long run.