HTML5 Doctor » canvas

Your Questions #16

Richard Clark — Tue, 01 Mar 2011 14:30:38 +0000

The clinic is getting busy with more HTML5 ailments! This week, we’ll cover the separation of formatting and content, custom elements, using

for social links, sections with no visible titles, and in the DOM.

Separation of formatting and content

Graham asked:

When I first started learning html and CSS I was constantly told not to use b or i tags as the idea was to completely separate formatting from content. Is this now not the case?

In HTML 4 (and XHTML 1.x), the elements and (plus some others) were presentational — they only had visual meaning. This doesn’t work so well for blind users, for example.

In HTML5, presentational elements have either been cut or, as in the case of and , given semantic meanings to make them media-independent. You can find out more here: The , , , and elements and The and
elements.

So to directly answer your question, in HTML5, and are now content (semantic), not formatting (presentational).

peace – Oli

Custom elements

Eric asked:

It is possible to use custom elements in HTML5 to be more semantic; however, is it ill-advised? For example:

Copyright ©...

Umm, no, HTML5 doesn’t allow “custom elements”. While browsers will try to recover gracefully if you do this, making stuff up is definitely ill-advised — something like will have no meaning for browsers and could lead to problems in IE.

If you want an element for a copyright statement or other short legalese, there’s already a perfectly good one in .

If you can’t find a more semantically appropriate element, use for phrasing (inline) content,
for a block of phrasing content, or
for flow (block-level) content, and add a class name that indicates the semantics — e.g. Lorem ipsum.

Hope that helps!

peace – Oli

Marking up social links

A reader asked:

Could a list of share icons (twitter, facebook, etc) be considered a candidate for use of the nav element? and do links in a nav element have to be into the same domain name”?

is for navigation around your content. On my personal site, I have a link to my Flickr photostream marked up in the same container as links to my own contact page, etc. I think the link to Flickr is conceptually no different to navigation within my personal site: it’s all my content. If my photos were on my own domain (as they used to be), I wouldn’t hesitate to include them in
, and I wouldn’t hesitate to include this same content within
today.

A list of share icons isn’t
for two separate reasons.

First, they aren’t meant to take you somewhere else. They’re designed to perform an action of tweeting/”liking” a link to a page.

Second, and most importantly, they’re not navigation around your content. As the spec says “Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element.”

As a list of share icons is tangential to your content, I’d probably use the
element: “The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography”. For more details, check out our
revisited article.

Social links are the kind of thing that could be cut from a feed reader without diminishing the value of the content. As an additional note, remember that you can also place an
at the end of an article, like a footer. In spite of its name,
doesn’t have to be a sidebar.

Thanks, Bruce and Mike

Sections with no visible titles

Francesco asked:

I have some divs, in a page, that semantically would make more sense as sections as there are natural headings for them, but they’re not written *inside* them, they’re outside. There are tabs to switch the visibility of these sections, and the tab navigation is on their left… so the actual title is only there, and not repeated inside of the sections. But besides that they really are sections… they even had “class=section” in the old version.

What would the best solution be? Put an h1 in there with display:none? It would make the outline correct, but it looks like a hack.

You should reorganise your markup to ensure the headings are within the section. Then you can use some CSS positioning trickery to move them into place. Don’t use display:none, though, as that’s invisible to everyone, including assistive technologies like screen readers.

Cheers, Rich

HTML5 and the DOM

Elango asked:

Is it possible to get the elements i have drawn into the canvas using some API. Say for eg i draw 2 circle and 2 lines is that possible for me to get these information from Canvas by using DOM API’s

No. Think of a canvas like a canvas you would physically paint on. If you paint a red stroke and then paint over that in blue, you can’t get back to the original red stroke. The canvas API works the same way: once your pixels are committed, you can’t go back.

You want SVG (or try out Raphaël).

Cheers, Remy

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Related Posts:

Your Questions Answered #10

Your Questions Answered #7

Your Questions #14

Your Questions #15

Your Questions #13

Your Questions #16 originally appeared on HTML5 Doctor on March 1, 2011.

video + canvas = magic

Tab Atkins Jnr — Wed, 20 Oct 2010 14:34:53 +0000

You’ve already learned about the and elements, but did you know that they were designed to be used together? In fact, the two elements are absolutely wondrous when you combine them! I’m going to show off a few super-simple demos using these two elements, which I hope will prompt cool future projects from you fellow web authors. (All of these demos work in every modern browser except Internet Explorer.)

First, the basics

If you’re just starting with HTML5, you may not be familiar with the element and how to use it. Here’s a simple example that we’ll be using in the later demos:

The element contains two attributes: @controls and @loop. @controls tells the browser to give the video the standard set of video controls: play/pause, scrubber, volume, etc. @loop tells the browser to start the video over again from the beginning once it ends.

Then, inside the element, we have three child elements, each pointing to a different encoding of the same video. The browser will try each source in order and play the first one that it understands.

See this code in action, playing the intro to one of the greatest cartoon series of all time.

HTML5 Video playing in Chrome

(A note about fallback: all of these demos assume that your browser has support, which isn’t true in IE8 or earlier. Normally, it’s good practice to specify a Flash fallback or similar for those browsers, but that wouldn’t accomplish much here — all of the techniques I demonstrate rely on basic integration between the element and the element, which you can’t achieve with a Flash player. So I’ve omitted any non- fallback content in these examples. I’ve still provided multiple sources, though, so all current browsers that do support will be able to play it.)

Now, a simple example

Now that we know how to play a video, let’s mix in some shenanigans. First, check out the demo, then come back here for a code walkthrough. I’ll wait.

…

Drawing video onto the canvas at full screen

Done? Cool! Now, how does this work? Surely it requires a few hundred lines of JavaScript, right? If you’ve cheated and already looked at the source code of the demo page, you’ll know how easy it is.

We start with this HTML:

Video/Canvas Demo 1

Same video code as before, but now with a element thrown into the mix. Kinda empty and useless at the moment, though. We’ll script it into action later.

Now, let’s pair that with some CSS to get things positioned right:

This just centers the video in the screen and stretches the canvas to the full width and height of the browser window. Since the canvas comes first in the document, it’ll be behind the video, exactly where we want it.

Now, here comes the magic!

Take that in for a moment. Just breathe deeply and absorb it. So short, so sweet, so pretty…

Now, let’s step through it.

var v = document.getElementById('v'); var canvas = document.getElementById('c'); var context = canvas.getContext('2d'); var cw = Math.floor(canvas.clientWidth / 100); var ch = Math.floor(canvas.clientHeight / 100); canvas.width = cw; canvas.height = ch;

This part is simple. I grab hold of the video and canvas elements on the page, and I grab the canvas’s 2D-context so I can draw on it. Then I do some quick calculating to find out how wide and tall I want the canvas’s drawing surface to be. The element itself is already stretched to the size of the screen via CSS, so this’ll make each pixel of the drawing surface equal to about 100×100 pixels on the screen.

That last bit may need some explanation if you’re new to canvas. Normally, the visual size and the drawing-surface size of a element will be the same. In that case, drawing a line 50px long will display a line 50px long. But that doesn’t have to be true — you can set the drawing surface’s size through the @width and @height properties on the element itself, and then change the visual size of the canvas with CSS to be something different. The browser will then automatically upscale or downscale the drawing appropriately to make the drawing surface fill the visual size. In this case, I’m setting the drawing surface of the canvas to be very small — on most screens, it’ll be about 10px wide and 7px tall — and then stretching the visual size with CSS so that each pixel I draw gets blown up 100-fold by the browser. That’s what causes the cool visual effect in the demo.

v.addEventListener('play', function(){ draw(v,context,cw,ch); },false);

Another simple part. Here I attach some code to the “play” event on the video element. This event gets fired whenever the user hits the “play” button to start watching the video. All I do is call the draw() function with the appropriate parameters: the video itself, the canvas’s drawing context, and the canvas’s width and height.

function draw(v,c,w,h) { if(v.paused || v.ended) return false; c.drawImage(v,0,0,w,h); setTimeout(draw,20,v,c,w,h); }

The first line just makes the function stop immediately if the user pauses or stops the video, so it’s not burning CPU when nothing’s changing. The third line calls the draw() function again, allowing the browser a little breathing space to do other things like update the video itself. I’m putting in a 20ms delay, so we’ll get roughly 50fps, which is more than enough.

The second line is where the magic happens — it draws the current frame of the video directly onto the canvas. Yes, it’s exactly as simple as it looks. Just pass the video element and the x, y, width, and height of the rectangle on the canvas you want it to draw into. In this case, it’s filling up the entire canvas, but you could do less (or more!) if you wanted.

I’m using another trick here. Remember how the canvas is really tiny? The video will be at least 20 times bigger than the canvas on most screens, so how do we draw it onto such a tiny canvas? The drawImage() function handles that for us — it automatically scales whatever you hand it in the first argument so that it fills the rectangle you specify. That means we authors don’t have to worry about averaging the pixel colors (or extrapolating, if you’re drawing a small video into a big rectangle) because the browser does it all for us. I’ll use this trick more in the future, so watch out for it.

And…that’s it! The entire demo is done in 20 lines of easy-to-read JavaScript code, instantly producing a nifty background effect for any video you wish to play. You can trivially adjust the size of the “pixels” on the canvas by adjusting the lines that set the cw and ch variables.

Directly manipulating video pixels

The last demo was cool, but it just let the browser do all the heavy lifting. The browser downscaled the video, drew it onto the canvas, and then upscaled the canvas pixels, all automatically. Let’s try our hand at doing some of this ourselves! Check out the demo to see this in action, where I convert the video to grayscale on the fly.

Video made greyscale with canvas manipulation

The HTML for the page is basically identical:

Nothing new here, so let’s move onto the script.

document.addEventListener('DOMContentLoaded', function(){ var v = document.getElementById('v'); var canvas = document.getElementById('c'); var context = canvas.getContext('2d'); var back = document.createElement('canvas'); var backcontext = back.getContext('2d'); var cw,ch; v.addEventListener('play', function(){ cw = v.clientWidth; ch = v.clientHeight; canvas.width = cw; canvas.height = ch; back.width = cw; back.height = ch; draw(v,context,backcontext,cw,ch); },false); },false); function draw(v,c,bc,w,h) { if(v.paused || v.ended) return false; // First, draw it into the backing canvas bc.drawImage(v,0,0,w,h); // Grab the pixel data from the backing canvas var idata = bc.getImageData(0,0,w,h); var data = idata.data; // Loop through the pixels, turning them grayscale for(var i = 0; i < data.length; i+=4) { var r = data[i]; var g = data[i+1]; var b = data[i+2]; var brightness = (3*r+4*g+b)>>>3; data[i] = brightness; data[i+1] = brightness; data[i+2] = brightness; } idata.data = data; // Draw the pixels onto the visible canvas c.putImageData(idata,0,0); // Start over! setTimeout(function(){ draw(v,c,bc,w,h); }, 0); }

The script is a bit longer this time, because we’re actually doing some work. But it’s still really simple!

document.addEventListener('DOMContentLoaded', function(){ var v = document.getElementById('v'); var canvas = document.getElementById('c'); var context = canvas.getContext('2d'); var back = document.createElement('canvas'); var backcontext = back.getContext('2d'); var cw,ch; v.addEventListener('play', function(){ cw = v.clientWidth; ch = v.clientHeight; canvas.width = cw; canvas.height = ch; back.width = cw; back.height = ch; draw(v,context,backcontext,cw,ch); },false);

This is almost the same as I had before, with two real differences.

First, I’m creating a second canvas and pulling the context out of it as well. This is a “backing canvas”, which I’ll use to perform intermediate operations before painting the final result into the visible canvas in the markup. The backing canvas doesn’t even need to be added to the document. It can just hang out here in my script. This strategy will be used a lot in later examples, and it’s quite useful in general, so take note of it.

Second, I’m waiting to resize the canvases until the video is played, rather than just sizing them immediately. This is because the element probably hasn’t loaded its video up when the DOMContentLoaded event fires, so it’s still using the default size for the element. By the time it’s ready to play, though, it knows the size of the video and has sized itself appropriately. At that point, we can set up the canvases to be the same size as the video.

function draw(v,c,bc,w,h) { if(v.paused || v.ended) return false; bc.drawImage(v,0,0,w,h);

Same as the first demo, the draw() function begins by checking if it should stop, then just draws the video onto a canvas. Note that I’m drawing it onto the backing canvas, which, again, is just sitting in my script and isn’t displayed in the document. The visible canvas is reserved for the displaying the grayscale version, so I use the backing canvas to load up the initial video data.

var idata = bc.getImageData(0,0,w,h); var data = idata.data;

Here’s the first new bit. You can draw something onto a canvas with either the normal canvas drawing functions or drawImage(), or you can just manipulate the pixels directly through the ImageData object. getImageData() returns the pixels from a rectangle of the canvas. In this case, I’m just getting the whole thing.

Warning! If you’re following along and trying to run these demos on your desktop, this is where you’ll probably run into trouble. The element keeps track of where the data inside of it comes from, and if it knows that you got something from another website (for example, if the element you painted into the canvas is pointing to a cross-origin file), it’ll “taint” the canvas. You’re not allowed to grab the pixel data from a tainted canvas. Unfortunately, file: urls count as “cross-origin” for this purpose, so you can’t run this on your desktop. Either fire up a web server on your computer and view the page from localhost, or upload it to some other server you control.

for(var i = 0; i < data.length; i+=4) { var r = data[i]; var g = data[i+1]; var b = data[i+2];

Now, a quick note about the ImageData object. It returns the pixels in a special way in order to make them easy to manipulate. If you have, say, a 100×100 pixel canvas, it contains a total of 10,000 pixels. The ImageData array for it will then have 40,000 elements, because the pixels are broken up by component and listed sequentially. Each group of four elements in the ImageData array represent the red, green, blue, and alpha channels for that pixel. To loop through the pixels, just increment your counter by 4 every time, like I do here. Each channel, then, is an integer between 0 and 255.

var brightness = (3*r+4*g+b)>>>3; data[i] = brightness; data[i+1] = brightness; data[i+2] = brightness;

Here, a quick bit of math converts the RGB value of the pixel into a single “brightness” value. As it turns out, our eyes respond most strongly to green light, slightly less so to red, and much less so to blue. So, I weight the channels appropriately before taking the average. Then, we just feed that single value back to all three channels. As we probably all know, when the red, green, and blue values of a color are equal, you get gray. (During this whole process, I’m completely ignoring the fourth member of each group, the alpha channel, because it’s always going to be 255.)

idata.data = data;

Shove the modified pixel array back into the ImageData object…

c.putImageData(idata,0,0);

…and then shove the whole thing into the visible canvas! We didn’t need to do any complicated drawing at all! Just grab the pixels, manipulate them, and shove them back in. So easy!

A final note: real-time full-video pixel manipulation is one of those rare places where micro-optimizations actually matter. You can see their effects in my code here. Originally, I didn’t pull the pixel data out of the ImageData object, and just wrote “var r = idata.data[i];” and so on each time, which meant several extra property lookups in every iteration of the loop. I also originally just divided the brightness by 8 and floored the value, which is slightly slower than bit-shifting by 3 places. In normal code, these sorts of things are completely insignificant, but when you’re doing them several million times per second (the video is 480×360, and thus contains nearly 200,000 pixels, each of which is individually handled roughly 100 times a second), those tiny delays add up into a noticeable lag.

More advanced pixel manipulation

You can operate on more than just a single pixel at a time, too, composing some fairly complex visual effects. As I noted at the end of the previous section, performance matters a lot here, but you’d be surprised what you can squeeze out with a little creativity. As you can see in the demo, I’ll be creating an emboss effect in this example, which requires you to use several input pixels together to compute the value of each output pixel.

Embossed video with canvas manipulation

Here’s the code. The HTML and most of the beginning code is identical to the previous example, so I’ve omitted everything but the draw() function:

function draw(v,c,bc,cw,ch) { if(v.paused || v.ended) return false; // First, draw it into the backing canvas bc.drawImage(v,0,0,cw,ch); // Grab the pixel data from the backing canvas var idata = bc.getImageData(0,0,cw,ch); var data = idata.data; var w = idata.width; var limit = data.length // Loop through the subpixels, convoluting each using an edge-detection matrix. for(var i = 0; i < limit; i++) { if( i%4 == 3 ) continue; data[i] = 127 + 2*data[i] - data[i + 4] - data[i + w*4]; } // Draw the pixels onto the visible canvas c.putImageData(idata,0,0); // Start over! setTimeout(draw,20,v,c,bc,cw,ch); }

Now let’s step through that.

function draw(v,c,bc,cw,ch) { if(v.paused || v.ended) return false; // First, draw it into the backing canvas bc.drawImage(v,0,0,cw,ch); // Grab the pixel data from the backing canvas var idata = bc.getImageData(0,0,cw,ch); var data = idata.data;

Same as the last example. Check to see if we should stop, then draw the video onto the backing canvas and grab the pixel data from it.

var w = idata.width;

The significance of this line needs some explanation. I’m already passing the canvas’s width into the function (as the cw variable), so why am I re-measuring its width here? Well, I was actually lying to you earlier when I explained how large the pixel array will be. The browser might have one pixel of canvas map to one pixel of ImageData, but browsers are allowed to use higher resolutions in the image data, representing each pixel of canvas as a 2×2 block of ImageData pixels, or maybe 3×3, or maybe even greater!

If they use a “high-resolution backing store”, as this is called, it means better display, as aliasing artifacts (jagged edges on diagonal lines) become much smaller and less noticeable. It also means that rather than a 100×100 pixel canvas giving you an ImageData.data object with 40,000 numbers, it might have 160,000 numbers instead. By asking the ImageData for its width and height, we ensure that we loop through the pixel data properly no matter whether the browser uses a low-res or high-res backing store for it.

It’s very important that you use this properly whenever you need the width or height of the data you pulled out as an ImageData object. If too many people screw it up and just use the canvas’s width and height instead, then browsers will be forced to always use a low-res backing store to be compatible with those broken scripts!

var limit = data.length; for(var i = 0; i < limit; i++) { if( i%4 == 3 ) continue; data[i] = 127 + 2*data[i] - data[i + 4] - data[i + w*4]; }

I’m grabbing the data’s length and stuffing it into a variable, so I don’t have to pay for a property access on every single iteration of the loop. (Remember, micro-optimizations matter when you’re doing real-time video manipulation!) Then I just loop through the pixels, like I did before. If the pixel happens to be for the alpha channel (every fourth number in the array), I can just skip it — I don’t want to change the transparency. Otherwise, I’ll do a little math to find the difference between the current pixel’s color channel and the similar channels of the pixels below and to the right, then just combine that difference with the “average” gray value of 127. This has the effect of making areas where the pixels are the same color a flat medium gray, but edges where the color suddenly changes will turn either bright or dark.

There’s another optimization here. Because I’m only comparing the current pixel with pixels “further ahead” in the data which I haven’t looked at yet, I can just store the changed value right back in the original data, because nothing will ever look at the current pixel’s data again after this point. This means I don’t have to allocate a big array to hold the results before turning it back into an ImageData object.

c.putImageData(idata,0,0); setTimeout(draw,20,v,c,bc,cw,ch);

Finally, draw the modified ImageData object into the visible canvas, and set up another call to the function in 20 milliseconds. This is the same as the previous example.

Wrapping up

So, we’ve explored the basics of combining HTML5′s and elements today. The demos were very basic, but they illustrated all the essential techniques you’ll need to do something even cooler on your own:

You can draw a video directly onto a canvas.

When you draw onto a canvas, the browser will automatically scale the image for you if necessary.

When you display a canvas, the browser will again scale it automatically if the visible size is different from the size of the backing-store.

You can do direct pixel-level manipulation of a canvas by just grabbing the ImageData, changing it, and drawing it back in.

In Part 2 of this article [Ed: coming soon!], I’ll explore some more interesting applications of video/canvas integration, including a real-time video-to-ASCII converter!

Related Posts:
An introduction to the Canvas 2D API
The video element
Review: HTML5 Now (DVD)
Your Questions #16
Native Drag and Drop
video + canvas = magic originally appeared on HTML5 Doctor on October 20, 2010.

Your Questions #13

Richard Clark — Tue, 28 Sep 2010 14:15:52 +0000

The clinic is getting busy with more HTML5 ailments. This week, we’ll cover server-side validation, immutable images with , retrieving drawn objects from a , creating custom tags, the role attribute, and the effects of
on SEO.

Server-side validation

Brian asked:

We currently use PHP-Tidy to validate the HTML mark-up of content regions of our site. Our content regions have images that represent modules in our system that get translated into code for things like processing video, forms, etc. I’ve been making the move to upgrade these modules to use new HTML5 elements, but I’m finding that Tidy is stripping out these elements and I’m doing a lot of dancing around these issues right now. Are you aware of any server-side processing scripts that have been updated to work with HTML5 and perhaps with ARIA support as well?

The current contender is html5lib. The PHP version is v0.1, so YMMV.

It seems that HTML5 support won’t be coming to Tidy anytime soon.

Good luck! Peace – Oli

Immutable image with

Mike asked:

We do have a medical app and we want to use to let docs draw over a still picture. The only thing I cannot do is keep the picture unchanged when they use an “eraser” (basically a white pen). I haven’t found any example on the web so may be it’s impossible. It seems that the background image either part of the canvas of a div containing the canvas becomes part of the canvas itself. If it’s possible what’s the secret? Thanks

This is possible in a variety of ways. Here’s a quick demonstration of one of the solutions. Open the demo up in Firefox 3.6 or later, drop an image in the box, draw over it, and click the “Drawn image as PNG” button to retrieve what you drew (without the background image).

Here’s what’s happening: the canvas is sitting inside of a
containing my still image, but I’m drawing on the nested (I think you had it the other way around, which was causing your problems).

Hope that helps, Remy

Retrieving objects from

DJ asked:

I wanted to know if there is any way in which the drawn objects say rectangle, circle, line, … within canvas can be identified based on the selection at later point in time (after they are drawn).

If there are no direct APIs how could we achieve it. Do we have to store the co-ordinates of each of the created object within and do the object identification based on mouse cursor? Thanks

Unfortunately, there’s no way to retrieve these objects unless you write your own system to handle it. There’s no native support for this in .

It sounds like you actually need to use SVG, which will allow to you to hook event listeners and query the DOM tree that’s created. If you need some convincing that SVG is the right tool for the job, have a look at the Raphaël JavaScript Library. It uses SVG exclusively and is able to create some very impressive drawings and animations.

Cheers, Remy

Custom tags

Mike asked:

So by using some JavaScript I can insert unfamiliar tags into IE, and using CSS I can format them. My question is why stop with HTML5 tags like section and nav? What are the pros and cons of custom tags like , , , or even , , ?

Custom elements go against having a standard like HTML5. Standards map out the set of elements, attributes, and APIs that the browsers need to implement so web developers can use them, and they provide those developers with a common approach to marking up a web page.

If custom elements were allowed, we would have an infinite number of ways to mark up content, many of which would share a common goal but require different implementations. As an example, here is a number of different elements I can dream up for some primary content:
, , , , ,
, , , , , , , , , , , , , and . Many of them are bad ideas, but hopefully you see my point. This doesn’t even account for the more predictable , , that would likely also be used.

This sort of markup would make HTML a nightmare to maintain. A developer coming into an existing site would have to learn which elements have been used and what their purpose is. And it’s not just painful for developers. Browser vendors would have to find ways to parse these elements and define how they should be used. Is this element supposed to be block-level? Is it interactive? Should it impact the document outline? And what about search engines? How do they know that defines the most important content on the page, the content that should really be indexed?

Standards narrow the possibilities and ensure developers, browsers, and machines (search engines and the like) are all speaking the same language. Many people spend a great deal of time debating the specification, trying to reach consensus on which proposals should be standardized and how they should be implemented.

So stick to the standards! They exist for everyone’s benefit. As browsers continue to implement the specification correctly (even IE is catching up), our jobs will be made easier and we can spend more time creating really cool things

John Alsopp’s fantastic article Semantics in HTML5 goes into more detail about this issue. You can also see where some of the element names came from by looking at the work Hixie did researching class names in Google’s index.

Regards, Mike

The role attribute, SEO, and

Robson asked:

What about the role attribute? Was it dropped from specification? What will be the “role” of the role attribute in HTML5?

Today, just the home page should have the name of the site into a H1 element. On others pages, the H1 should be used to the title of the articles. How do search engines interpret the HGROUP and multiples HEADER and H1 elements today? How to implement the HGROUP and the HEADER today without impact the SEO? Thanks, guys!

To answer your first three questions, role is in. You can use it belt-and-suspenders style until assistive technology catches up with HTML5. Just be careful: “Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below”.

For the second part of your question, that’s not true. You can use more than one
in HTML 4/XHTML 1. It’s not advised to make every heading
in HTML 4/XHTML 1 (because historically some people did that to spam), but it may be appropriate in some cases — e.g., site name and page title. Using two
‘s on a single page has no effect on SEO.

With regard to
and
, you’re asking the wrong question. Search engines care about high-quality, relevant content. Search engines penalise spamming, but writing markup according to the specification is not spamming. The HTML5 editor works at Google, so they’re well aware of the spec. html5doctor.com has implemented and
, and it hasn’t hurt our search engine rankings any

For more, see our articles on the header element and the hgroup element.

You probably don’t want to use
everywhere anyhow, as CSS selectors are not that smart. If you wrap every
-
in a sectioning element (
,
,
,
), you don’t have to worry about keeping a logical order for your headings. Doing this means you don’t need to overwrite CSS as much. The old style, however, with the requirement to keep a logical order for your headings, still works.

Again, you’re concerned with the wrong thing. Good SEO = good content. Worrying about placement or what search engines think is a waste of time — worry about good content.

Peace – Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Related Posts:

Your Questions Answered #11

Your Questions #16

Your Questions Answered #7

Your Questions Answered #5

Your Questions 18

Your Questions #13 originally appeared on HTML5 Doctor on September 28, 2010.

An introduction to the Canvas 2D API

Remy Sharp — Tue, 03 Aug 2010 13:30:06 +0000

If the element is the poster boy of HTML5, then is definitely Danny Zuko. The element is (still) part of the HTML5 specification, but the 2D drawing API has been moved into a separate document (in case you go looking and can’t find it).

has a wealth of features, like:

drawing shapes,

filling colours,

creating gradients and patterns,

rendering text,

copying images, video frames, and other canvases,

manipulating pixels, and

exporting the contents of a to a static file.

In fact, the canvas API is so interesting, I wouldn’t be surprised to see entire books dedicated to it (and no, I don’t plan to write that book!).

It’s important when working with to treat it like a real painting canvas. Say you lay down a strip of red paint on a real canvas. If you paint over it in blue, you can’t get back to your original red paint. It’s the same with the canvas element. There’s no concept of layers. The element is a bitmap drawing API, and once you’ve committed to a set of pixels, you’re stuck with them.

Four of the Big Five browsers support canvas. We’re naturally missing IE8, but there’s hope: IE9 does support canvas. In fact, it supports hardware accelerated drawing to the canvas — other browsers currently don’t, making IE9 preview 3 the fastest (canvas) kid on the block!

Always consider the options

Before we dive in to the canvas API, I want to remind you to make sure you’re using the right technology for the job.

SVG is the alternative drawing API. It’s vector-based and does support layers. SVG also exists in the DOM, making it easy to attach event handlers for interactivity, and it’s easier to deal with collision detection (in games, for example). It also supports animation either through SMIL or JavaScript. There’s an excellent JavaScript library called Raphaël that uses SVG to render images and animations.

The element is good for pixel manipulation and highly active animations. Brad Neuberg does a really good job of explaining the differences in his Google IO talk from back in 2009.

With all that in mind, let’s crack on with the canvas API.

Hello Canvas

The element by itself is an invisible block of space, by default 300×150 pixels (in all browsers):

So now we’ve got a blank canvas in front of us. To draw, we need the drawing context, which we can get using JavaScript. Once we have the context, we can draw abominations to our hearts’ content:

Code snippet

The context is our direct access to draw and paint on the canvas. Without it, we can’t paint a thing.

Painting Shapes

The 2D drawing API is fairly large (not too huge, but bigger than most other HTML-esque APIs), so I’m just going to show you how to draw something simple: a solid blue rectangle and a pink semi-circle.

Using the context object from earlier, we’re going to call fillRect(), passing the method the coordinates of the top left corner (x, y) and the width and height of the rectangle we want to paint:

Code snippet

Simple filled rectangle created with canvas

If you don’t specify a colour, the default fill and stroke colours will be black. So let’s change that to blue by setting the fillStyle() before we call fillRect(). We’re choosing our colour before drawing because this is just like a real canvas — if you’re going to paint, you need to dip your brush in to the paint pot first:

var canvas = document.getElementById("c"), context = canvas.getContext("2d"); context.fillStyle = 'blue'; context.fillRect(10, 20, 200, 100);

Code snippet

Blue filled rectangle created with canvas

Being the eagle-eyed HTML5 ninja that you are, you noticed that I’ve used the string blue as the fill colour. You can use any CSS colour properties in the canvas API. That means blue, #0000ff, #00f, rgb(0, 0, 255), and even rgba(0, 0, 255, 0.5) are all valid colours.

How about we turn this thing up to eleven? Let’s add a pink semi-circle. Oh yeah! Let’s do this!

var canvas = document.getElementById("c"), context = canvas.getContext("2d"); context.fillStyle = 'blue'; context.fillRect(10, 20, 200, 100); // setup the line style context.strokeStyle = '#fa00ff'; context.lineWidth = 5; context.lineCap = 'round'; // draw the arc path // (I'll walk you through these values momentarily - bear with me!) context.arc(50, 50, 20, 0, Math.PI, false); // colour the path context.stroke();

Code snippet

Blue filled rectangle with a semi-circle created with canvas

There are three things that we’ve added to our JavaScript:

Configuring the line style

Drawing the semi-circle path

Stroking the path (i.e., painting the line)

When drawing paths, until you fill or stroke the path, nothing appears on the canvas. In this case, our path is an arc of a 180 degrees. The arc() method takes the following arguments: x coordinate, y coordinate, radius, start angle, end angle, and whether the arc should be drawn anti-clockwise. All of these arguments are required. (Technically, if you’re drawing a circle, it doesn’t matter whether you’re going clockwise or anti-clockwise, but you still need the argument.)

The tricky parts are the start and end angle. They’re both in radians. Remember those? I didn’t, so I’ll forgive you if you don’t! Here’s how to convert from degrees to radians:

var radians = degrees * Math.PI / 180;

It’s common to pass 360 degrees to the drawing methods, which is simply Math.PI * 2. Similarly, 180 degrees is Math.PI, which we used to create our semi-circle.

Once you have your path, you need to stroke (or fill) it. This applies the line style and colours to the path and completes our drawing. Do please remember that with this drawing: a) you can’t recover those lost blue pixels under the pink semi-circle, and b) this example would be much simpler in SVG!

So remember to choose the element based on its strengths as I outlined at the top of this article.

Exporting & Saving

One thing that SVG can’t do is save the resulting image as a bitmap. It’s easy for because the element is already a bitmap in the first place! The canvas can export its image to a data URL (e.g., data:image/png;base64,iVBORw0KGg...). This data may then be rendered in the browser, which could then be saved or dragged to the desktop, used in a new canvas, and so on.

The browser must support PNG images, and it may have varying support for GIF and JPG. For our example, we’ll stick with PNG since it supports alpha transparency, and where we haven’t drawn on the canvas, it’ll be transparent.

To get the data URL, we simply call canvas.toDataURL('image/png'). Note that we’re calling toDataURL() on the element, not on the 2D context. This is because we’re getting all the pixels in the canvas, not just the pixels in a particular context.

So taking the example we’ve put together already, we’ll make the browser redirect to a PNG version of the image when a user clicks on the element (a contrived example, I know!):

canvas.onclick = function () { window.location = canvas.toDataURL('image/png'); };

Code snippet

If you go to the live canvas example and click on the element, it will load a PNG version of the canvas. Now you can save that to your desktop, email it to your friends, or even tweet it to your followers!

That’s just the start

This is just a small preview of what the canvas 2D API can do. There’s a whole lot more:

Gradients, fills, and patterns

Paths

Text

Pixel manipulation

Animations (though old school, flip book style)

And don’t worry, the HTML5 Doctors will publish more articles explaining the canvas API in the future. We’ll even have special guest Tab Atkins explaining how he got a video to render entirely in ASCII!

In the meantime, here are a few useful resources to keep you going.

Further reading

Mozilla’s canvas tutorial

Opera’s canvas tutorial

Breakout game live tutorial

Mark Pilgrim’s Dive in to HTML5 canvas chapter — but don’t forget there are other good books you can buy too
Related Posts:
video + canvas = magic
Your Questions #16
Your Questions #13
Your Questions Answered #11
Review: HTML5 Now (DVD)

An introduction to the Canvas 2D API originally appeared on HTML5 Doctor on August 3, 2010.

Your Questions Answered #11

Richard Clark — Fri, 30 Jul 2010 14:00:13 +0000

The clinic is busy as ever with more HTML5 ailments. This week, we’ll show you how (and whether) to store a on the server, whether to use or , more on
, the placeholder attribute, and HTML5 minification.

Getting info from a canvas to the server

Stephen asked:

I want to use a canvas element as a layout plan and allow people to move things about and the like but I then want to be able to submit the changed layout to the server so it can be kept not just as a bitmap but as the various current layout of the plan. Is this possible?

You could call canvas.toDataURL() and store this output on the server. (Note that canvas is the DOM node and not the 2D context.) This will store the current state of your canvas, but it’s effectively a bitmap at this point. If you want to store the element for later editing, I’d suggest you use SVG instead. You can achieve the same graphical effect, but you’ll have access to the actual vector data since it’s XML.

Hope that helps,

Remy

Progress or meter?

Pierre asked:

Hello doctor,

I’m beginning with HTML5. I just wonder if I’m using the progress and meter elements correctly. Just imagine a player. Is it correct to use: the progress element to specify a load bar; the meter element to specify the volume set.

Thank you Doctor, have a good day.

is spot on for a loading bar, yes.

is read only, however, so it’s not appropriate for a volume control. There are some examples in Tom’s article on . To create a volume control, you could use one of the new input types specified in HTML5, perhaps .

Cheers,

Rich

Headers

Brad asked:

Having read you can use the header tag within almost any other element, is it fair to say you no longer “design” the header but simply design the elements in each header? How does that work? Would you use header classes?

In the past you define your header with an image or text etc. You can no longer do that if you use multiple headers?

The
element should be used if you have any related information within the “header” of that section that needs to be grouped. This means, for example, it isn’t necessary to wrap a lone
in a
element. Also remember that the header doesn’t have to appear at the top of a section of page.

Our articles on the
element and element explain this some more.

Whether you need to use classes depends on your site.

Ta,

Rich

The placeholder attribute

José asked:

I recall once having seen text inputs that had tips inside them. They didn’t need Javascript in order to manage those tips. Would you consider discussing that a little better? That’d be great! Thanks!

We’re publishing an article on forms shortly, so be sure to look out for it.

Meanwhile, you’re looking for the placeholder attribute. Currently, this is supported only on Webkit browsers, although Mozilla is also working on it. You can use placeholder like this:

We’ve also written a JavaScript solution using feature detection (i.e., it will check whether the browser supports placeholder and adds support if not). Just add this script to the end of your markup (note that it should be the end since it needs to run once the DOM is ready).

Hope that helps,

Bruce & Remy

HTML5 Minified

Grant asked:

Hello! Big fan of your website. I wanted to know about the so called “HTML Minified” feature that allows you to strip the html, head and body tags from your page.

The W3C Validator Conformance Checker for HTML5 says this is valid, but the Conformance Checker is beta and is supposedly unreliable. I haven’t heard from anywhere else that stripping these tags is a feature.

So is it really a feature? Or just a bug (A BIG one at that) in the experimental validator? I know that it works, but I would like to see any confirmation other than the validator that this is in fact an intended standard before I start using it on my websites. Thanks!

According to the spec, it is now explicitly permitted to omit all kinds of ~~elements~~ tags, including the ones you mention. Browsers are able to deduce the document structure based on context (e.g., some elements are only allowed within a element) and will fix the DOM as they go. In fact, these have always been optional tags in HTML (but not XHTML).

Browsers are so good at this, though, because they’ve had to deal with the pants code out there on the interwebs. Going this route means you’re relying on browser error handling to render your document ~~(although said error handling has admittedly been standardised in HTML5)~~. I personally see it as a more extreme version of quoting element attributes. Of course you don’t have to, but being strict makes errors much easier to find, helps out parsers that may not be as sophisticated as a full-fledged browser (like text editor syntax highlighting), and makes it easier for beginners and veterans alike to learn and use HTML.

In general, machines understand you better when you’re explicit, so I’d advise against omitting these elements.

For more detailed articles on HTML5 minification, check out Remy’s HTML5 Boilerplates and Bruce’s A minimal HTML5 document.

Peace,

Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Related Posts:
Your Questions Answered 9
Your Questions Answered #7
Your Questions #13
Your Questions Answered #5
Your Questions Answered #8
Your Questions Answered #11 originally appeared on HTML5 Doctor on July 30, 2010.

Your Questions Answered #10

Richard Clark — Fri, 09 Jul 2010 12:45:00 +0000

The clinic is getting busy with more HTML5 ailments. This week, we’ll cover using sections within a footer, vs. Flash security, why HTML5 elements are treated as inline, using offline with storage, and marking up block quotes.

Footer with sections

Tommie asked:

Hi, I’ll get to the point right away. I want to use, lets say 3 section elements inside a footer each floating left and inside each of this sections I have some standard information. Is this the right way to go, or should I put my section elements outside the footer and only put copyright text etc. inside the footer?

Thanks!

You could use a
within
. but
is a sectioning root anyway
is flow content and can contain sectioning content. If you want them to appear in the outline within the footer, then it makes perfect sense to do as you suggest.

See more in Jack’s article on the
element. There are also some more examples in the spec.

Cheers, Rich

vs. Flash (security and copyright)

John asked:

I’m seeing lots of opinions that the canvas element might free us of the Adobe Flash monopoly, but what mechanisms can we use to protect our works when using straight HTML and JavaScript?

Right now I’m thinking about simple flash games, but I’m sure this is a concern for others wanting to use (free) HTML methods to perform functions now reserved more for flash.

Thanks for any input.

I’m not sure of any security mechanisms that we can use to protect content. It isn’t really any different than an image or any other type of resource. Having said that, decompilers can circumvent some of Flash’s security measures as well, so you may not be much worse off using .

If we come across anything, we’ll be sure to let you know.

Cheers, Rich

HTML5 tags inline?

Tami asked:

So, I’ve been experimenting with the new HTML5 elements, and one frustration I have is understanding the native display of the new elements, and how it works within the document flow. So far, experimenting with them has shown them to be very unpredictable. At best, they’re kind of behaving like a bastard span. They seem to be behaving like inline elements but that seems like it is wrong. In some cases, setting to display: block gives the expected behavior, but on the footer tag, it’s not interacting with floated elements properly.

So, are these new elements inline or are browsers still just trying to catch up? I tried looking in in the HTML5 working draft spec, but so far I am not understanding the way its written (HTML4′s specs clearly spelled out whether an element was display or inline).

Here’s an article from my personal blog that I wrote a while ago describing why browsers treat HTML5 elements as inline.

Thanks, Bruce.

Offline + Storage

Dear Doctor, I’m trying to work out if HTML5 will be able to do the job that I want. I have a number of documents (PDF, PPT, etc.) that I want to share with people in my team. These documents may change from time to time. Also, the people may not always be connected online.

Would it be possible to “cache” documents in an offline database in the browser so that when they are not connected they can still view them but when they are, they get the latest versions (which also refresh the cache)?

That way I can do a fairly pretty interface for sorting these documents so that they can easily find them.

Thanks in advance for any help you can provide.

You can, but I would strongly encourage you to think carefully about whether it’s worth it.

You can include these “assets” in the manifest, which will make the files available to the offline applications (note that this isn’t storage, just caching, which is what you’re after).

The problem is that when the visitor first hits the page with the manifest — which contains all the PDFs, PPTs, etc. — it will download all of these files. This is the bit that I’d encourage you to consider carefully. To compound that, I believe there’s a 5MB limit on the cache, so you might run into problems if you’re trying to cache more than that.

I’ve not covered offline cache on HTML5 Doctor yet (though it’s on the list), but I have described the process on my 24ways article.

If there are new versions of the cached files, you need to change the contents of the manifest — e.g., include a version number, which will trigger a download of all the assets again. Not ideal, but that’s the current situation.

Hope that helps a bit, Remy

Correct markup with blockquote

Phil asked:

Hi, in HTML 4.0 Strict and XHTML 1.0 Strict, text inside a blockquote element is required to be nested inside another block-level element, e.g. p.

In HTML5 that requirement seems to have been relaxed, as the following element validates successfully:

This is a blockquote.

The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required.

Can you please confirm if this requirement has now been deprecated?

Great question. As I expected, this validates:

blockquote test Tiger tiger burning bright

We double-checked with the WHATWG mailing list and confirmed that
can contain ‘flow’ content (i.e., text, paragraphs, etc.).

To summarise, it would be valid not to further mark up content within a
, but authors are encouraged to use a
(or other more appropriate element).

Bruce

Got a question for us?

That wraps up this round of questions! If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Related Posts:
Go offline with application cache
Your Questions Answered 9
Your Questions #16
Your Questions Answered #12
Your Questions Answered #7
Your Questions Answered #10 originally appeared on HTML5 Doctor on July 9, 2010.

Why designers should care about HTML5

Cennydd Bowles — Wed, 14 Oct 2009 13:01:06 +0000

After a while on the fringes of our collective consciousness, HTML5 is finally getting the attention it deserves. The development community (as typified by the SuperFriends) has come together to debate practical elements of the spec, argue over the inclusion of controversial elements, and assess the timeframe over which we can unleash HTML5 in the wild.

However those of us more accustomed to the world of Post-Its, sketches, and .psds – the designers – haven’t been so vocal. Perhaps we’ve been distracted by the bright lights of CSS3 and those surface thrills we’ve longed for. (Rounded corners! Gradients! Transparency!) Or, alternatively, we’ve been in the thrall of @font-face and looking forward to the coming age of passable web typography.

Understandable. But it’s time designers got excited about HTML5 too.

Partly, it’s just good practice. Whatever your flavour of design – visual, web, interaction, user experience – knowing the native technology makes you better at your job. Just as composers should understand the capabilities of the orchestra’s instruments, designers need to understand the language of the web.

But there’s more to HTML5 than simply keeping our skills sharp. It could make a big difference to the way we design for the web.

Semantic elements

Information architects (and, by extension, user experience designers) should be excited by the new HTML5 elements –
,
,
and so on. While they won’t immediately revolutionise today’s web, they’re an investment for the future. Doing useful stuff with information is the central theme of IA, and therefore its practitioners should be at the forefront of the new experiences that machine-readable semantics will offer. HTML5 allows us to mark text up in a more meaningful way than a sea of
s, meaning we’ll soon see applications appearing at a sub-page level. We’ve started to scratch the surface – think about the Operator toolbar or customisable UIs à la iGoogle – but we’ll need detailed design thinking to work out how to bring the benefits of semantic richness to the end user.

APIs and other extensions

While it’s clear that some of the HTML5 APIs are far from perfect right now, when they’re refined they will offer us intriguing new opportunities and challenges.

Designers of location-based services should of course find the geolocation API invaluable. The contentEditable attribute gives us further power to make the web truly read/write without resorting to JavaScript and custom interfaces. New input types (eg type="search") can provide extra visual cues about input function, although of course this depends on the solutions chosen by the browser manufacturers.

Until now, it’s been easy to consider our domain as bounded by the viewport and the web server. But HTML5 is another step toward seamlessness: the merging of desktop, offline and online. For instance, the drag and drop API could see the line between online and desktop experience blur further. Local storage could allow for a web-like experience in areas of poor connectivity. This convergence is clearly a good thing, but we must also design how to expose those hidden seams at the user’s request. Users should stay in control of how their locations are published and what data is synchronised to their machine.

, ,

There is of course something of a reported schism between the standards world and the Flash world. Some see the advent of these new media elements (particularly ) as heralding the death of Adobe’s poster child.

I don’t think this is either likely or desirable. Neither technology is perfect. Flash is, of course, proprietary and thus subject to the whims of a third party that stands between browser and user. has known accessibility problems. But the two can live in harmony, if we play to their respective strengths. Some current Flash applications might be better suited to , particularly those based around dynamic visualisation: graphs, animations, infographics. Some applications will benefit from the powerful capabilities of Flash: games, heavily interactive widgets.

This aside, there’s clearly a user experience benefit in not having to rely on an external plugin to play rich media elements, and it will be interesting to see the uptake of the and elements. Although it will initially be down to browser makers to define the interface elements involved, we will need to figure out how to integrate them into everyday web experiences. The good news is that they can be styled in the same way as any other HTML element. If your visual aesthetic relies on slanted images with box shadows, it’s trivial to apply this to video too.

That said, we can’t ignore the elephant in the room: the thorny codec issue. I’m sure we’d all agree that the sooner it’s resolved, the better.

What can designers do?

Only the most patient and detail-oriented designer will relish the idea of reading the spec in full and arguing the finer points on the WHATWG list. That’s just not the way designers roll.

But as a community it’s important that we start talking about HTML5. If you’re new to HTML, now’s a great time to learn. The articles on this site and A preview of HTML5 give useful guidance on the differences between HTML5 and its predecessors. Above all, designers should get chatting with their developer friends: there can’t be many left who no longer have an opinion on this technology. How do they see their practices changing? What can we do today to prepare our sites for the advent of HTML5? How can we build on its strong points to make the web a better place?

We don’t yet know what we’ll accomplish with HTML5, but then it’s not often that the vocabulary of the web changes this deeply. However, one thing is clear: if we prepare now, we have a great chance to bring innovation to our users’ online lives.

This article was jointly published on Ineffable, Cennydd’s personal website.

Related Posts:

Reviewing HTML5 for Web Designers

HTML5: briefing notes for journalists and analysts

Native Audio in the browser

HTML5 Doctor at Web Directions @media

Draw attention with mark

Why designers should care about HTML5 originally appeared on HTML5 Doctor on October 14, 2009.

HTML5 Doctor » canvas

Your Questions #16

Custom elements

Marking up social links

Sections with no visible titles

HTML5 and the DOM

Got a question for us?

Related Posts:

video + canvas = magic

First, the basics

Now, a simple example

Directly manipulating video pixels

More advanced pixel manipulation

Wrapping up

Related Posts:

Your Questions #13

Server-side validation

Immutable image with

Retrieving objects from

Custom tags

The role attribute, SEO, and

An introduction to the Canvas 2D API

Always consider the options

Hello Canvas

Painting Shapes

Exporting & Saving

That’s just the start

Further reading

Related Posts:

Your Questions Answered #11

Your Questions Answered #10

Footer with sections

vs. Flash (security and copyright)

HTML5 tags inline?

Offline + Storage

Correct markup with blockquote

Got a question for us?

Related Posts:

Why designers should care about HTML5

Semantic elements

The `role` attribute, SEO, and