Style Scope with HTML5 Canvas

When working with HTML5 Canvas, we're constantly interacting with the canvas context object, which contains an abundance of cool styling properties and drawing methods.  For a typical block of code that draws something onto the canvas, we draw a path, set a handful of context properties to style whatever it is we're drawing, and then use methods like fill() and stroke() to actually draw things onto the canvas.  Piece of cake, right?
But what happens if we're creating large, complex canvas applications, and we have lots of methods and functions that draw things onto the canvas which can be executed in any order?  We certainly don't want styles from different parts of our code base leaking into other parts of the code base.  Here's an example:

Code Editor

As you can see, we're calling drawTransparentSquare() followed by drawSquare().  Since objects can be modified by reference in JavaScript, when the first function set the global alpha property to 0.5, the style leaked over into the next function call and made the second square transparent as well.  This obviously wasn't the desired result.
So what can we do do?  Should each of our methods and functions reset the context styles like a CSS reset for each function?  Although this could be achievable by creating a resetStyles() function which loops through all of the styling properties and sets them to their default values, it seems a bit odd to constantly reset all of the style properties each time a function call is made.  Is there a better way?

Style Scope Induction

Style scope refers to the scope of styling inside of code blocks, similar to the notion of variable scoping inside of code blocks.  When writing JavaScript code, for example, it's good practice to split the code base into a collection of modular methods and functions, such that variables created within each function are scoped only to that particular function, and aren't accessible outside of it.  This is called variable scope induction.  What we need here, is a way to induce style scope within a function, or any other block of code, in such a way that the styles applied to the context don't leak over into other functions or blocks of code.

The HTML5 Canvas State Stack: A Diamond in the Rough

One of the most powerful, and probably the most overlooked features of the HTML5 canvas, is the state stack.  The state stack stores snapshots of styles and transformations in a stack data structure via the save() method of the canvas context.  What's even more important is that we can also use the state stack to restore snapshots of styles and transformations with the restore() method.
So how can we use the state stack to induce style scope?  If we use the save() method at the beginning of a function definition, we can save the state of the canvas context in the state stack.  Once the state is saved, we can apply several context styles, draw things, and then restore the state stack back to the initial state with the restore() method.  Viola, we've just induced style scope.

HTML5 Canvas

Welcome to Basic Tutorials! In these tutorials we'll focus on the fundamental drawing capabilities of the HTML5 Canvas.

HTML5 Canvas Basic Tutorials Prerequisites

All you need to get started with Basic Tutorials is a modern browser such as Google Chrome, Firefox, Safari, Opera, or IE9, a good working knowledge of JavaScript, and a simple text editor like notepad.

HTML5 Canvas Element Tutorial

The HTML5 Canvas element is an HTML tag similar to the div, a or table tag, with the exception that its contents are rendered with JavaScript.  In order to leverage the HTML5 Canvas, we'll need to place the canvas tag somewhere inside the HTML document, access the canvas tag with JavaScript, create a context, and then utilize the HTML5 Canvas API to draw visualizations.

When using canvas, it's important to understand the difference between the canvas element and the canvas context, as often times people get these confused.  The canvas element is the actual DOM node that's embedded in the HTML page.  The canvas context is an object with properties and methods that you can use to render graphics inside the canvas element.  The context can be 2d or webgl (3d).
Each canvas element can only have one context.  If we use the getContext() method multiple times, it will return a reference to the same context object.

Differences Between HTML4 And HTML5

Now that we've seen how to use some of the newer whiz-bang features of the draft HTML5 standard, it's time to take a few steps back and take a look at some of the other differences between HTML4 and HTML5.

This article is intended to be a useful overview, not an exhaustive reference, but remember that things are still and always changing. You also may want to refer to this document for the actual details of the HTML5 specification itself.

The first thing you should know is that, perhaps for the first time, the development of a language standard is acknowledging the real world. In order to keep file compatibility with the current standard - which is technically HTML 4.01 - the brave decision was made to separate the way the web browser renders files from the way we, as developers, must write them. So the browser, or "user agent", must still process HTML4 constructs like the center element, because there will still be millions of files on the Internet that happen to use it. But we won't be writing any more HTML with center; it's simply being dropped from the language (use CSS instead). This compatibility goes both ways: older browsers can (and will) simply ignore HTML5 code without screwing things up.

No More Frames

This is great news to those of us who slogged through the 1990s. To be exact, the elements frame, frameset, and noframes are being removed from the language, as well as acronym, applet, basefont, big , blink, center , dir, font, isindex, strike , tt and u. All of these can be handled using CSS or other methods.

You'll also have to learn to get along without using tables for layout; while tables themselves are still part of HTML5, they're not intended for placing pixels any more. Here's what the spec says:

"Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming, because tools attempting to extract tabular data from such documents would obtain very confusing results."

So all the attributes that let people create those perfectly laid-out, tinted tables are gone, like align, bgcolor, border, cellpadding, cellspacing, height, nowrap, rules, valign, and the big one: width. The mantra: use CSS instead.

I've been trying my best to break it to you slowly, but frankly, all presentational elements are coming out of HTML5. My advice: learn lots more CSS, until you can quote chapter and verse in your sleep.

 

Good News

The good news is that even though this is a big change, it's a change for the better. Browsers of the future (just another month or two!) will become more powerful because of the move towards the cloud, so that they'll be able to handle more on their own. We've already seen that with things like Ajax, and now with video/audio embedding and such, it will be far easier for us to code in a straight forward manner and let the browser figure out the details. For instance, new structure elements include article, aside, figcaption, figure, footer, header, hgroup, nav, section, and summary, all of which refer to the structure of the document itself and leave rendering to the browser.

There are still some new elements that deal with text on a detailed level, however: you'll code wbr when you think it's possible to do a line break, but the browser will decide for you. Another hint element is bdi, used to mark an area where bidirectional text formatting can be done (primarily for mixing left-right and right-left languages in a single document). Its complement, bdo, lets you explicitly override and force a particular directionality. For even more slick internationalization, the elements ruby, rp, and rt are included for ruby annotations, which are meant for pronunciation aids rather than for Ruby On Rails programmers.

The more high-level new elements include things like canvas, meant for specifying an area for drawing a bitmapped graphic on the fly, such as a data graph or game graphic; meter is a placeholder for a numeric measurement of an expected size (and is eerily similar to format in ancient FORTRAN), while progress is its graphical counterpart, to be used where you want a progress bar. Last, but not least, there are the multimedia elements (audio, video, source, embed).

 

HTML5 New Elements

New Elements in HTML5

The internet, and the use of the internet, has changed a lot since HTML 4.01 became a standard in 1999.
Today, several elements in HTML 4.01 are obsolete, never used, or not used the way they were intended. All those elements are removed or re-written in HTML5.
To better handle today's internet use, HTML5 also includes new elements for drawing graphics, adding media content, better page structure, better form handling, and several APIs to drag/drop elements, find Geolocation, include web storage, application cache, web workers, etc.

• The New Canvas Element

• New Media Elements

• New Form Elements

• New Semantic/Structural Elements

 HTML5 offers new elements for better structure: We will discuss all these elements in next article.