Tag Archives: html5

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

Coloring the HR element line in CSS

I never, ever use this element, but HR has been bequeathed new life in HTML5 and I may start using it for providing more thematic break awesomeness to my already blindingly-awesome prose and poetry.

Anyway, someone asked me this question: Is color supported in all browsers by the HR element? To which I replied: “I have no clue. Let me investigate.”

Here’s an initial test:

Well hambone. Using the text rule for color on WebKit browsers yields no color change. Works fine in all cases in Firefox. IE gives no quarter to the border-color CSS property, but works fine with the text color value. Every browser supports HTML color attributes, but you know that using presentational markup is as wrong as Michelle Bachmann’s views on evolution and vaccination, so you just say no.

So what’s a poor web dev to do? Define a border width:

Replacing the original border-color rule with the shorthand listed here, or just providing an explicit border-width property, will render a consistent 2 pixel line in all browsers. If we just wrote something like border:thin solid red; we’d get a 2-pixel border – see you’d think the HR element is just a line, but in fact the browsers all treat it like a box it seems. So we have to clear it out with border:none; and then add a border-bottom or border-top rule to set a 1 pixel line. If you want different widths, you have arguably more accurate control by only having to argue with one border instead of two.

What… you want to replace that HR with a background image? Good idea. Check out this post at Neatly Sliced for the answer, and gird your loins for the usual IE kludgeries.

A quick book review: Responsive Web Design

Just finished reading an excellent book: “Responsive Web Design” by Ethan Marcotte. If you build web pages, I want you to read this book. Here’s a few of my thoughts on what I just learned, and why you should read this one too.

The book begins with an overview of the evolution of page layout in web design, starting with it’s roots in printed page design and moving on to today’s reality that there is a multitude of screens and devices out there, with more on the way. We cannot predict what type of device our readers will show up with, and must adjust our belief system (if we have one) to accommodate the new realities that the various screen widths and mobile device sizes present us with.

The second chapter discusses the idea of designing within the constraints of a flexible typographic grid. Grid systems are somewhat of an artificial constraint that designers place on themselves to provide balance and symmetry to page layout, and on screen a new challenge is presented in that the page size is no longer fixed. The main takeaway here is to design content in flexible porportions to the variable screen widths that might be used to access your web pages. Mr. Marcotte puts forth some simple, accessible ideas for developers to leverage, making text more readable on unknown devices by putting forth a formula that I’ll repeat here mostly for the purposes of getting my own head wrapped around it:

target ÷ context = result

To decode Mr. Marcotte’s example, he begins with an assumption of a base font size of 16px. The headline in the comp is defined to be 24px. So to make it flexible, divide:

24 ÷ 16 = 1.5

And so the headline should be defined as 1.5em. Simple and elegant rule of thumb. Now we just need to remember to do it.

Chapter 3 applies this principle to flexible images, and expands upon it. There is the inevitable Questionable Functionality Challenge™ presented to us by Internet Explorer, which is quickly defused. That’s a lot of ink to dedicate to an obsolete web browser and the example demonstrates where the real problem lies by showing how awful text looks in resized images. But you aren’t locking up text in your images, right? I know, I know, it’s an academic example and clearly illustrates the failings of IE’s image resize capabilities. Let’s move on.

Chapter 4 introduces media queries. We’re finally at what I consider to be the coolest and most important part of the book – how to progressively enhance your web page layouts through the media query construct. Mr. Marcotte makes the argument in favor of using the min-width property instead of things like max-width (which tends to yield excessive code) and min-device-width (which only pertains to devices and doesn’t take into account variable web browser windows.) The max-width property is introduced for those that want to stop the insanity. (I do know people that expand their web browser to the full width of their 27″ high resolution monitors.)

Chapter 5 pulls it all together with strategies to integrate responsive design into your team’s workflow; how to make your design process itself a responsive one. He builds the case for Luke Wroblewski‘s “Mobile First” philosophy (a case that was already built up a bit in chapter 1) and finishes it all of with how to incorporate progressive enhancement using JavaScript to selectively pull in a slideshow component only when JavaScript is available and all the stars are in the proper alignment.

Overall, my belief has always been somewhat of the philosophy that there should be just “one web”; no “mobile web” or any other sort of alternate web reality that we should somehow slip into. Today’s mobile devices that are in fact being used to access the web are billed as fully capable web browsing devices, and indeed they are. Why deliver a shrunken-down version of your website just because they have a 3″ wide screen these days? It no longer makes sense in most cases; just reposition your content to accommodate their view. Every chapter includes simple, usable techniques that work, and I feel that these gems of advice should be a core part your future projects.

Lastly, I am very thankful for the appearance of the A Book Apart series. Each one of these volumes is, I believe, how a tech book should be: concise, full of valuable, practical, actionable information. I have read several of these so far, and each one has been a hit. I look forward to more.

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.

Exploring New HTML5 Elements

The next article in the Developing with HTML5 series.

Nothing endures but change.


The HTML5 draft specification includes many new elements and attributes for enhanced structural and semantic clarity. Most of the old elements still exist too, and you can still use them if you like. But the new elements will serve to make your markup clearer, more compact, and more functional in modern web browsers. Let’s take a look at some of these elements and what they mean for web developers in scientific contexts. For starters, here’s a list of the new elements, along with links to the relevant points in the specification:

Heraclitus by cote on Flickr

A first glance at HTML5 structure

The first elements we should look at are the structural ones:

article, aside, figcaption, figure, footer, header, hgroup, nav, and section. Take a look at those names for a moment. Think how many times you’ve formed your markup in a fashion resembling something like the following code:

In particular, I’d like to direct your attention to the ID and class attributes for header, article, and footer. These are major structural components that are common in everyday markup. Use of these semantic structures is so common, that it made sense to construct elements around them. Here is the same code as the above, refactored in HTML5:

In the revised HTML5 version, things are much clearer to read. Your eye can readily follow where the beginning and end of the structural blocks are, because they have structural names such as article and footer instead of just generic div elements with nondescript element closings.

The specification defines header as “a group of introductory or navigational aids.” This could mean navigation, tag lines, section headings, logos, etc. In this example, we use this element to define the masthead of a page, but it could just as easily be a child of a navigation element or an article too – if that’s what the content semantically would require.

The article element represents a defined, distributable piece of content. This might be a press release, a journal article, a blog post, or even a status message such as we’d see on Twitter. We used it here to begin our piece of pulp fiction. (I’m sure there’s more to the story – perhaps at the next NaNoWriMo I’ll use that as a germ for an actual story…)

Heading groups

Oh, one more thing about this section that we should address, and here’s where things get interesting: the tagline. Right now we have a paragraph tag with a class of tagline. And if we’d like to keep that formatting in place, that’s fine. However there’s a new construct in HTML5 that we can leverage, so let’s take a look at the hgroup element:

Here what we’ve done is to change the tagline paragraph into an h2 element, and wrap the h1 and h2 elements inside of an hgroup. The hgroup element is a heading, and can only contain two or more of h1 through h6.

Sectioning off headings

Furthermore, you can use the section element to help structure your document. In a nutshell, consider that any heading within a section is one level lower than headings of the same face value outside of it. Consider the following markup:

These are all h1 elements, but structurally the hierarchy is represented as so, due to the nestings of the section elements:

  • Homininae
    • Gorillini
      • Gorilla gorilla
        • Gorilla gorilla gorilla
        • Gorilla gorilla diehli
      • Gorilla beringei
        • Gorilla beringei beringei
        • Gorilla beringei graueri
    • Hominini
      • Pan
        • Pan traglodytes
          • Pan troglodytes troglodytes
          • Pan troglodytes verus
          • Pan troglodytes vellerosus
          • Pan troglodytes schweinfurthii
        • Pan paniscus
    • Homo
      • Homo sapiens
        • Homo sapiens sapiens

It’s turtle headings, all the way down

In the code, we had all h1s, but the spec requires that the hierarchy is interpreted as shown in this list, and we can clearly see that say homo sapiens sapiens is a subheading of homo sapiens, which is in turn a subheading of homo, then finally homininae. But why does this matter? Well, consider for a moment that the HTML5 specification only allows specific headings of h1 through h6. Then consider if we were to extend our taxonomic classification to encompass all mammals. We’d run out of headings before we got to homininae! In this manner, we can use the h1 element ad infinitum within it’s own section elements, and if we needed we can throw in a little h2 through h6 if needed. If we run out, just add more sections.

A small caveat, however: Having an endless stream of h1s means today’s screen readers used by disabled users might have trouble dealing with the hierarchical order of your content, and there is no functional CSS or other construct currently available to work around this problem. If you have accessibility issues to contend with, stick with the traditional usage of h1 through h6 for now, even if you use heading within.

Go figure

The figure and figcaption elements are for inserting and captioning figures in text documents. Before, we didn’t have an effective way to mark up figure images, and certainly had to come up with creative ways to mark up captions. These elements wrap this problem up nicely.

As a side note…

The only structural elements I haven’t mentioned yet is the aside element. The aside element indicates related information. It could be used for what we consider typical “sidebar” content in a web page layout, or it could be an aside in a story – such as a text box titled “learn more” in a feature news story or textbook-style article of content. This element may have it’s own headings, nav, content, and whatnot, and if it is found occurring within an article then it is considered related to that given article of content.

And that just about wraps up an introduction to HTML5 with a brief overview of the core structural and hierarchical elements. As we move forward with this series, we’ll take a look at the other new elements mentioned above, as well as look at some of the ways HTML5 has refactored existing markup to have new meaning.