AIAIO: Our Blog

AIAIO: Our Blog

The pulse of Alexander Interactive

HTML5, round 3: The canvas tag

A new element introduced in HTML 5 is the <canvas> tag which can be used to draw graphics by means of a scripting language such as JavaScript. In the markup, it acts very similar to the HTML <img> tag, but there is no need for src or alt attributes – only width and height can be used, but both are optional. With no values given, the area will default to 300px wide and 150px high. Below is a simple example of what the markup would look:

<canvas id=”draw” width=”500″ height=”300″>
<p>Your browser does not support the canvas element.</p>
</canvas>

While <canvas> does not require a closing tag in Safari, it is required in Firefox and is best practice to always use one so the element will render properly in all supportive browsers. The <p> is used for alternative content when a user’s browser does not support <canvas> – an <img> can be used here as well. Alternative content could not be utilized if a closing tag is not used. An id attribute is used in the code sample in order to identify the element in the JavaScript.

Like all other HTML elements, <canvas> can be styled with CSS (margin, border, etc.) but those styles will not be applied to the actual content within the <canvas>. In the example below, a dotted border is used to display the actual <canvas> element:


Your browser does not support the canvas element.

When viewed in a supportive browser, two rectangles should be seen above – One green, one opaque blue. This example is quite simple and just a mere demonstration of the ability to draw with JavaScript.

One of the nice features of the <canvas> element is text replacement, generally tackled by sIFR (Flash-based text replacement). Cufón is a text replacement method which utilizes the <canvas> as a means to display copy with the specific font of choice. One major drawback to the Cufón method is the amount of HTML code generated, making a simple heading element bloated enough to make a developer cringe. While it is better than sIFR, with the need for a third-party (Flash) plugin to be installed, it is still not a perfect means for text replacement.

Accessibility with the <canvas> element is a concern for many developers. There are no current native methods to generate markup from the content produced within the <canvas>. Using alternative content can be helpful but it must be manually input by the developer, and it will not be true to what the element’s actual content is displaying.

The methods used to create <canvas> content is rather pain-staking, considering the end result. Drawing with JavaScript creates many lines of code, and the end result does not seem worth it. Some great examples of what people are cooking up with this new element are located at www.canvasdemos.com. There are definitely some cool effects that can be used to make a website more lively, but in terms of practical use I don’t foresee a heavy use of this new element. It seems to be more application-driven for a specific purpose (see: Tiny Doodle), which most websites will have little to no use for. Once <canvas> becomes more widely-used and supported it is likely that scripting libraries, similar to MooTools, will be built. This would enable developers to create <canvas> content with much more ease.

Technology

Leave a Comment

* = required