HTML5 Doctor » Bruce Lawson

Video: the track element and webM codec

Bruce Lawson — Thu, 24 Jun 2010 13:45:42 +0000

There are a couple of interesting developments in the world of HTML5 multimedia that you’ll be interested in. The first is the new element (currently only in the WHAT-WG spec due to political stuff).

is a child of a or element that links to a timed track, or time-based data. The kind of data is set via a kind attribute, which can take values of subtitles, captions, descriptions, chapters or metadata, depending on the type of information you’re adding to your media. These point to a source file containing timed text that the browser will expose via some kind of user interface, if the visitor requires additional data.

This will allow for “write once, use everywhere” accessibility; anyone linking to that file with a or element that includes the element can access your information.

The file format is a new format called WebSRT, which competes with about 50 other timed formats, including some W3C formats (hence the omission of from the W3C spec).

Added 9 July 2010: Here’s a readable overview of the SRT format.

Given that the format itself isn’t fully specified yet, it will be a while until we see implementation in browsers. But it’s good to know that there will be an official way to add accessibility information to media. Until then, I have a JavaScript hack to take timed s out of an in-page transcript to superimpose over a video.

WebM video format

The big news of the last month is that Google open-sourced the VP8 video codec that it acquired when it took over On2 Technologies. When combined with the Vorbis audio codec (that Spotify uses) and wrapped in a subset of the Matroska container format, it’s collectively known as WebM.

All YouTube videos are being transcoded to WebM, and Adobe have also announced they will include it in their Flash player. It’s available in an Opera 10.60 beta, a Firefox testing build, and a Chromium dev channel. Even Microsoft have said that IE9 will support it if the codec is installed on the computer.

The VP8 video codec itself is high-quality (Google had said that Ogg Theora wasn’t good enough compression-to-quality for YouTube, but Theora was based on the VP3 precursor to VP8). It’s available for streaming too.

If you want to encode to WebM, you can try the Miro Video Converter utility. Although it doesn’t allow you to optimise settings, it’s very easy to use. As the codec becomes more widespread, expect to see many more tools for content creation, editing, and transcoding.

Once production versions of the browsers are available, you should encode your videos with WebM as the first option, Ogg for older versions of Opera, Firefox and Chrome, falling back to royalty-encumbered H.264 for Safari and links to downloads or a Flash player for legacy browsers:






Your browser does not support video; download the WebM, mp4 or Ogg video for off-line viewing.

If, however, you’re having problems with the iPad, put the MP4 version first in the element; apparently there’s a bug that causes the iPad only to see the first element.

It’s a long haul, and it’s not over yet, but and .webM show significant progress towards our goal of accessible, open, and royalty-free video playing natively in the browser.

Share and Save:

Video: the track element and webM codec originally appeared on HTML5 Doctor on June 24, 2010.

The nsfw element

Bruce Lawson — Thu, 01 Apr 2010 07:30:20 +0000

Among the new semantic elements for section, footer, header, and the like, HTML5 also adds an element that can contain any other element and describes it as Not Safe For Work (commonly abbreviated to “nsfw”).

Browsers can be configured by parents or workplace sysadmins never to show content marked as , thereby shielding faint-hearted people from obscenity and protecting employers from employees downloading things they shouldn’t.

It’s not just a presentational element, although it does carry with it the default CSS:

nsfw { display: none; }

The user agent is forbidden from downloading any of the resources contained within the element if the browser’s setting is “on”.

It works like this:


 
 
 
 Huge cockerel: two chicks, one coop.

The entire figure is taken out of the document flow with no indication to the user that something is missing (which could tempt teenagers to circumvent the browser setting). Although the video is set to autoplay, it will never even be downloaded, meaning nothing compromising will be in the user’s cache.

The new element was suggested by Ian Hickson, the editor of the HTML5 spec and Google employee: “Google builds a separate index for those who search using Google SafeSearch. Given that 72.3% of the Web is not safe for work but we currently have to analyse that using machines, semantically marked-up porn and foul language will dramatically reduce the time it takes to build our index, enhance its accuracy and, most importantly, protect little children.”

So far, it is not implemented in any browser, although in its recent IE9 announcement, Microsoft confirmed that IE9 and its Bing search engine will use a Microsoft-only extension instead of the standard .

Share and Save:

The nsfw element originally appeared on HTML5 Doctor on April 1, 2010.

The time element (and microformats)

Bruce Lawson — Tue, 09 Feb 2010 14:49:14 +0000

Microformats are a way of adding extra semantic information to a webpage using HTML classes — information like an event’s date and time, a person’s phone number, an organisation’s email address, etc.

They aren’t a “standard” per se, but they are a widely adopted convention within the geek community. And since they use an agreed-upon set of class names, they are as compatible with HTML5 as they are with HTML4 or XHTML.

HTML5 offers one potential addition to the microformats arsenal. Because earlier versions of some microformats presented accessibility problems in the way they encoded dates and times (see an article called hAccessibility that I co-wrote with James Craig), HTML5 offers a new element for unambiguously encoding dates and times for machines while still displaying them in a human-readable way.

The format is very simple: 13 November 2009:

The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset.

W3C specfication

You can have whatever you want between the tags, so:

13 November 2009
13^th November
Bruce's 21st birthday
8PM on my birthday
8PM on my birthday—in Tokyo

are all equally valid.

Note that the last example has an optional timezone offset (+09:00) too (thanks, Oli!). You can also use “Z” (e.g. 2010-11-13T20:00Z) to represent Universal Coordinated Time (UTC), which is the equivalent of the timezone +00:00. Finally if you don’t specify a timezone offset the time is “local time” (in this case England).

The fly in the ointment

The only trouble with is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″. Microformats, however, aren’t subjected to this restriction and are often employed to mark up, for example, very old events on Wikipedia or imprecise dates on museum websites. It’s likely that authors will continue using the current, more flexible microformat patterns unless the restrictions on the element are lifted. (The HTML5 working group has been continually petitioned to remove their arbitrary restrictions and widen the scope of time, but with no success).

Perhaps because of this restriction, current microformat clients can’t consume microformats such as hCalendar if they’re coded to use . Stefan Schipor wrote to us saying, “The problem is that I need to parse the site with H2VX or any other similar thing for exporting. Sadly, H2VX doesn’t seem to read the datetime attribute in the elements. Nor does the FF add-on Tails. I tried the microformats IRC channel and the microformateers twitter account but I didn’t get any response. Do you know if there is any support for this? It would kill me to add elements just for it to work.”

Incorporating the `pubdate` attribute

This doesn’t mean that is an a waste of time, or that it’s more trouble than it’s worth (a white element, as it were). It has a great deal of scope outside microformats, too.

On my personal blog, I use it to mark up publication dates of articles. There is a boolean attribute pubdate specifically for this:


  
  My brilliant blogpost
  Published on 20 January 2010 in the Sexysocks category.
  
  I'm wearing sexy socks! Here's a picture.
  ...

The spec says:

The pubdate attribute is a boolean attribute. If specified, it indicates that the date and time given by the element is the publication date and time of the nearest ancestor article element, or, if the element has no ancestor article element, of the document as a whole.

You might be wondering why the pubdate attribute is needed at all. Why not just assume that any element in an

’s

is its publication date?

Consider this example:


  
  Come to my party on 1 March
  Published on 20 January 2010 in the Sexysocks category.
  
  I'm throwing a sexy socks party at Dr Naughty's Ladyboy Cabaret Roller-disco Bierkeller Pizza-parlour-a-gogo! Do come.
  ...

You’ll see that there are two dates within the

: the date of the actual party and the publication date of the article. The pubdate attribute is required to remove any ambiguity.

Where could time be used?

The uses of unambiguous dates in web pages aren’t hard to imagine. A browser could offer to add events to a user’s calendar. A Thai-localised browser could offer to transform Gregorian dates into Thai Buddhist era dates. Content aggregators can produce visual timelines of events.

Search engines can produce smarter search results. For example, in the recent heavy snow in the UK, I searched for school closures in my town and discovered my kids’ school was closed. After receiving a phone call from the school asking me where my kids were, I re-examined the webpage. In small print at the bottom of the page were the words "Published 5 January 2008". I expect that operators of search engines would rank more current pages more highly on searches connected with current events.

Share and Save:

The time element (and microformats) originally appeared on HTML5 Doctor on February 9, 2010.

Hello, summary and figcaption elements

Bruce Lawson — Mon, 01 Feb 2010 10:42:38 +0000

This weekend saw the minting of not one but two new elements. The summary element (not the summary attribute on the table element) goes inside the details element:


More information
Here is the source data that is discussed in the article ...

This is designed to produce an “expando” box that is closed by default (but can be open by default using the boolean open attribute), only displaying the text specified by the summary as a control. Activating that control opens the whole details element; re-activating closes it again. If no summary text is present, the browser defaults to the rubric “details”. (Added 4 Feb 10:) In browsers that support details, this behaviour does not depend on author scripting, and should work even if JavaScript is disabled or not present.

figcaption lives inside the figure:


 (or video, table etc)
A rabid unicorn goring a fairy.

If you want some history, continue reading. Otherwise, bye bye!

Previously, the legend element was specified to do the job of both. Unfortunately, every browser had parsing problems re-using it outside forms. Similar problems were encountered attempting to re-use the caption element outside tables. At Jeremy Keith’s suggestion, the spec then re-used dd and dt, but that breaks too.

Now, two new elements are minted. (I quite fancied one new element – rubric for both, but it’s a pretty esoteric word.)

One of the objections to details, as described by Shelley Powers in her bug to remove it is

the use of JavaScript for the purpose of expanding or collapsing a section is both well-defined and common among web applications. More importantly, following the concept of progressive enhancement, these types of expanding sections are expanded by default if script is turned off. To have a section that is dynamic but not controlled by script is going to cause confusion, particularly among people who turn scripting off and are assuming that there are no “expando” sections in the web page.

In fact, I don’t see how this element will make developing web applications that much simpler. This type of functionality is trivial with JS.

My counter-argument was that an expanding/ collapsing area on the page is a very common requirement. I’ve seen sites pull in a whole JavaScript library just to accomplish this (presumably as the developer was unfamiliar with JS), which bloats the page size for the user. I’ve seen pages where the “details” information is set to display:none by default, and the user cannot expand the information without JS, thereby making the contents inaccessible if JS is not present.

Reinstating this element would be advantageous to developers, who wouldn’t need to learn JS to accomplish a common task; advantageous to users who would get an accessibility bonus from having this behaviour natively in the browser.

While I like to think that the irrefutable logic of my argument, coupled with the tear-jerking rhetorical flourishes in my prose captured both the heart and the head of the editor, I suspect what persuaded him was Apple’s Maciej Stachowiak saying that “the webkit community” were interested in implementing details once the spec was nailed down. Implementation wins the day.

Share and Save:

Hello, summary and figcaption elements originally appeared on HTML5 Doctor on February 1, 2010.

The section element

Bruce Lawson — Fri, 11 Sep 2009 12:38:17 +0000

We doctors are a bunch of chums using HTML5 and writing about how we do it. Apart from spurious requests for medical advice, the questions we receive most are about using the section element, and we realise that we’ve been using the section element incorrectly all this time.

Sorry.

What we’ve been doing wrong is using section to wrap content in order to style it, or to demarcate the main content area from the nav, header, footer etc. These are jobs for div, not section.

The section spec says

The section element represents a generic document or application section…The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead.

section is a blob of content that you could store as an individual record in a database. It generally looks like this (and note that the heading goes inside the section element, not immediately before it):


Any level of heading
rest of the content

With very few exceptions, section should not be used if there is no natural heading for it. Check your work in the HTML 5 outiner tool. If you see any instances of “untitled section” that corresponds to a section, you’re probably doing it wrong. (It’s fine for a nav or aside element to be untitled, however).

Section is also the most generic of the sectioning elements. Make certain that you don’t really need an article, which is defined as

a composition that forms an independent part of a document, page, application, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, an interactive widget, or any other independent item of content

What about main content?

In HTML 5 you can specifically mark up all the “secondary” content on a page such as navigation, branding, copyright notices, so it feels odd that you can’t specifically mark up the most important part of your page—the content.

But what would be the purpose of marking it up specifically, anyway? If you need to style it, use a div. An assistive technlogy like a screenreader can find the main content because it is the first thing inside a page that isn’t a header, nav or footer.

Rules of thumb for using `section`

Of course, there are always exceptions, but these should give useful guidance for 99% of cases:

Don’t use it just as hook for styling or scripting; that’s a div
Don’t use it if article, aside or nav is more appropriate
Don’t use it unless there is naturally a heading at the start of the section
The revised spec (as of 16 September) says:

Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.

As blogposts and comments are often syndicated (by being pulled into other blogs or being linked via twitter, reddit etc) they should be articles.

Thanks to Opera’s Lachlan Hunt for fact-checking this article. Please also note that we haven’t yet changed the WordPress theme to get rid of extra sections, so for now please do as we say and not as we do!

Share and Save:

The section element originally appeared on HTML5 Doctor on September 11, 2009.

It’s bug report time!

Bruce Lawson — Fri, 21 Aug 2009 14:57:43 +0000

As HTML 5 begins the last lap to the fabled W3C stage of Last Call, the editor Ian Hickson has requested that any problems with the spec be reported using the Bugzilla tool rather than simply the mailing list.

You need to register to use it, and then reply to a confirmation email. That’s it. Happy griping!

Share and Save:

It’s bug report time! originally appeared on HTML5 Doctor on August 21, 2009.

“Block-level” links in HTML5

Bruce Lawson — Mon, 13 Jul 2009 12:00:06 +0000

One new and exciting thing you can do in HTML 5 is wrap links round “block-level” elements.

Imagine you have a front page with lots of teasers for news articles, each of which leads to a page devoted to the full text of that article. Obviously, each story needs a heading and you’ll want an image too, and you’ll want them all clickable. In current mark-up you’ll probably have something like this:


Bruce Lawson voted sexiest man on Earth
A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.
Read more

Note that you have three identical links (or two if, like the BBC News site, you assume your readers don’t need a “read more” link).

In HTML 5, you code it like this:



Bruce Lawson voted sexiest man on Earth
A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.
Read more

Now the single link surrounds the whole teaser, removing duplication and creating a much wider hit area to click.

Two points to make about accessibility in passing: firstly, you don’t need to worry that each "read more" goes to a different destination (see WCAG 2) because the whole story is the link, so the link text is unique. Secondly, note that I’ve changed the alternate text on the image, as in the first instance the image is a link so I described its destination, whereas the second is just a picture so I describe the image itself—”gorgeous lovebundle”—and thereby give more information to a screenreader user.

Shiny, but not new

What’s also very interesting about this technique is that actually this isn’t new: you can do it now. XHTML 2 had a similar mechanism, which allowed href on any element Eric Meyer called for this to be adopted in HTML 5 but, of course, this isn’t backwardly compatible. One of his other solutions to the same problem was changing the rules for a, and my test page shows that it works now in all the browsers.

That’s one of the interesting things about HTML 5—it documents existing browser behaviour. As the browsers already handle wrapping links around block-level elements, and there is an obvious use-case, there was no reason to artificially keep the structure as invalid.

(One irony: Eric Meyer’s original use-case was to link all cells in a table row. This doesn’t work in HTML 5; you need script for that.)

Share and Save:

“Block-level” links in HTML5 originally appeared on HTML5 Doctor on July 13, 2009.

HTML 5 + XML = XHTML 5

Bruce Lawson — Thu, 02 Jul 2009 14:20:41 +0000

(Also available in Spanish Traducción de “HTML 5 + XML = XHTML 5″ and Portuguese.)

I like the xhtml syntax. It’s how I learned. I’m used to lowercase code, quoted attributes and trailing slashes on elements like br and img. They make me feel nice and comfy, like a cup of Ovaltine and The Evil Dead on the telly.

But you might not. You might want SHOUTY UPPERCASE tags, no trailing slashes and attribute minimisation. And, in HTML 5, you can choose.

Thanks to the “pave the cowpaths” principle, it’s up to you. As you like it. What you will. Whatever you want, whatever you like.

But let no-one tell you that HTML 5 kills XML—meet XHTML 5.

XHTML 5 is the XML serialisation of HTML 5 and, as you’d imagine, it has all the stricter parsing rules that you’d expect (and are used to if, like me, you grew up with XHTML DOCTYPES). It must be served with an XML MIME type, such as application/xml or application/xhtml+xml (so no rendering in Internet Explorer for the moment) and will throw a wobbly at the slightest well-formedness violation. (See Serving XHTML with the Right MIME Type for more information.)

Usual XML rules apply: no document.writes allowed, no DOCTYPE required, some syntax and script differences to trip up the unwary and you can use namespaces.

The main differences are summarised on the official WHATWG wiki Differences Between HTML and XHTML. It’s also possible to write polyglot documents that can be processed as either by browsers, depending on the MIME type used.

Magne emailed the Doctor to ask “Is it OK to use HTML5 tags in a page with the XHTML 1.1 doctype? Which one should I use, as in, which one is the recommendation now?”

If you want to use the new features, you need to use HTML 5 DOCTYPE or XHTML 5. Given that Internet Explorer cannot process XML, for pragmatic reasons the Doctor advises HTML 5.

Share and Save:

HTML 5 + XML = XHTML 5 originally appeared on HTML5 Doctor on July 2, 2009.

Designing a blog with html5

Bruce Lawson — Tue, 30 Jun 2009 14:00:21 +0000

Much of HTML 5’s feature set involves JavaScript APIs that make it easier to develop interactive web pages but there are a slew of new elements that allow you extra semantics in your conventional Web 1.0 pages. In order to investigate these, let’s look at marking up a blog.

Firstly what we’ll do is use the header, footer, and nav elements to mark up the broad structure of the page. We’ll make the blog comments form much smarter by using the new data types and built-in validation available in HTML 5-aware browsers.

Then we’ll do some work on the guts of the page, using HTML 5’s article elements to better mark up blog posts and comments and show how to use the section elements to better structure accessible hierarchical headings on sites that are CMS-driven. As blogs are chronologically ordered, we’ll see what HTML 5 offers us for representing dates and times.

So take the phone of the hook, and make a cup of tea and we’ll get started.

Setting the DOCTYPE

HTML 5, when used as plain HTML rather than its XHTML 5 sibling doesn’t need a DOCTYPE. But all browsers do, otherwise they go into Quirksmode, which you don’t want: the collision of HTML 5 and Quirksmode is like matter and anti-matter meeting, and will cause a negative reality inversion that will make your underwear catch fire.

You’ve been warned, so at the top of your document, you need the line .

Some sites “use” HTML 5, when in actual fact all they’ve done is take their existing code and change the DOCTYPE. That’s fine and dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences between the languages, summarised in the document HTML 5 differences from HTML 4.

However, I don’t want simply to rebadge my existing code, but to use some of the new structural elements now.

Using some new structural elements

My blog – like millions of others – has a header denoted by

, a footer

, some articles (wrapped by an area called “content”,

) and some navigation (wrapped up in an area called “sidebar”

). Most sites on the Web have similar constructs, although depending on your choice they might be called "branding" or "info" or "menu", or you might use the equivalent words in your own language.

Although these all have very different functions within the page, they use the same generic div in the markup. as HTML 4 has no other way to code them. HTML 5 has new elements for distinguishing these logical areas: header, nav, footer and friends. (There’s more on this in an artice by Lachlan Hunt on A List Apart: A Preview of HTML 5.)

The overall aim is to replace this structure:

with this:

It’s a simple matter to change the HTML divs into the new elements. The only difficulty I had was deciding which element to use to mark up my sidebar, as it also includes a search field and “colophon” information as well as site-wide navigation. I decided against the aside element, as the spec says it “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”, but it’s nevertheless content rather than navigation. So I decided to go for the nav element as the closest fit.

I’ve wrapped the main content in a section element (previously I’d kept it as a div). section is defined in the spec

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.

Please note: I no longer recommend wrapping the whole content area in a section element, and suggest that you use a div element. Read more about using section appropriately.

In this case, the “generic document section” is that of main content. I’ve retained an id so that a skip links feature will work, although I hope that in the future, assistive technology will offer an automatic way for people to go to the first section or article.

My fellow HTML 5 doctor, Remy Sharp, also notes that if you retain the div, Internet Explorer without JavaScript would style the div, but none of the other content, making the site very hard to read.

New form attributes

As well as the main structural item on the page, I’ve added some new attributes on input elements in the comments form.

HTML 5 was designed to reflect what developers actually do rather than to reflect a philosophical purity, and that’s very clearly manifested in the new attributes which mean the browser takes up much of the work currently done by developers re-inventing validation routines in JavaScript. (Extending forms functionality was how the HTML 5 spec began).

So I amended the email input field in the comments to be input type="email" which means that when the user submits the form, an HTML 5-aware browser will use built-in validation routines to check that it’s in the correct format, without any JavaScript. Check it out in the current version of Opera, as that the only full implementation at the time of writing (June 2009), and note that it also adds a “mail” icon in the input field as a cue to the user.

There are similar input validation routines triggered by some of the new input types, such as url (which I use on the field that asks for the user’s web address), number and pattern which compares the input with an arbitrary regular expression.

Another good example is input type="date", which pops up a calendar widget/ date picker when the user focusses on the input field. You can test the date picker, or here’s a screenshot from Opera 9.6:

A very useful new attribute I used on both input fields for commenter’s name and email address, and the comment textarea was type="required" which generates a message on submission if the fields are left blank. Each different localisation of a browser would need to have a different message, and it’s not (so far) customisable by the developer.

The good thing with all this new form fabulousness is it’s all formed around new attributes on an exisiting element, so people using older browsers just see a plain old input field.

A note on screenreaders and HTML 5

I hope screenreaders are ready for these new interactions; I asked the html 5 group to formally invite screenreader vendors to participate in the specification; to my knowledge, none have done so.

Laying out the new elements

It’s not too hard to layout the new elements. In all the non-IE browsers, you can lay out anything using CSS – even a nonsense element. One gotcha is that that the current crop of browsers have no “knowledge” of these elements, although support is improving all the time.

All browsers have default settings for the elements they “know about”—how much padding, margin they element gets, does it display as a block or inline?. (Here’s a sample default stylesheet.) Unless over-ridden by CSS, these defaults apply. But the browsers don’t know about header, nav and the like, so have no defaults to apply to them.

I got terrible rendering oddities until I explicitly told the browsers

header, footer, nav, article {display:block;}

IE layout

There’s one gotcha about styling HTML 5 pages in IE: it doesn’t work. You can force it to quite easily with a JavaScript hack document.createElement('element name'). (Lachlan Hunt gets to the bottom of why IE needs this.)

For your convenience, Remy Sharp has written an HTML 5 enabling script which I use in the header to conjure all the missing elements into existence all at once.

But let’s be clear: this won’t work if your IE user doesn’t have JavaScript turned on. How much of that’s a big deal that is for you to decide. Pragmatically, it seems to me that the sites that will benefit the most from HTML 5’s new “Ajax”-style features, such as drag-and-drop, are the sites that currently have no hope of working without JavaScript.

Firefox 2 and Camino 1 layout

Firefox 2 and Camino 1 both use Gecko 1.9 which has a bug and so gets grumpy if you don’t serve the page as XHTML. (Go figure; that’s almost enough to trigger a negative reality inversion and you know how bad that can be). However, Firefox and Camino users upgrade frequently so Firefox is in version 3, while Camino 2 beta is out, so the problem will soon cease to exist. (Read more at How to get HTML5 working in IE and Firefox 22 by Remy Sharp.)

What’s the point of those new structural elements?

Well, they add semantics to the page. The browser now knows which area of your site is the header or the footer because there are header and footer elements, whereas div might be called “branding” and “legal”, or even “en-tete” and “pied-de-page” or “kopfzeile” and “fusszeile“.

But so what?

Robin Berjon expressed it beautifully in a comment on A List Apart:

Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why. So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics?

The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?” … I think HTML should add only elements that either expose functionality that would be pretty much meaningless otherwise (e.g. canvas) or that provide semantics that help repurpose for Web browsing uses.

In my view, there are a couple of things I want to do with those semantics. The first is for search engine use; it’s easy to imagine Messrs Google or Yahoo! giving lower weighting to content in footer elements, or extra weight to content in the header. The second reason is to make the site navigable for people with disabilities. People with learning difficulties might instruct their browser always to put the articles before the navigation, for example. User agents might very well have a keyboard shortcut which jumped straight to the nav for example, or jumped straight past the navigation, in a programmatic implementation of “skip links“.

Which brings me to…

Further refining the HTML 5 structure

The blog home page

An interesting thing about a blog homepage is that there are generally the last 5 or so posts, each with a heading, a "body" and data about the post (time, who wrote it, how many comments etc.) and usually a link to another page that has the full blog post (if the homepage just showed an excerpt) and its comments.

HTML 5 has an article element which I use to wrap each story:

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.

Let’s look in more detail at the guts of how I mark up each blogpost.

Anatomy of a blog post

The wrapper is no longer a generic div but an article. Within that is a header, comprising a heading (the title of the blogpost) and then the time of publication, marked up using the time element.

Then there are the pearls of wit and wisdom that consitute each of my posts, marked up as paragraphs, blockquotes etc., and is pulled unchanged out of the database. Following that is data about the blog post (category, how many comments) marked up as a footer and, in the case of pages that show a single blogpost, there are comments expressing undying admiration and love. Finally, there may be navigation from one article to the next.

Data about the article

Following the content there is some “metadata” about the post: what category it’s in, how many comments there are. I’ve marked this up as footer. I previously used aside which “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” but decided that it was too much of a stretch; data about a post is intimately related.

footer is a much better fit: “A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.” I was initially thrown off-course by the presentational name of the element; my use here isn’t at the bottom of the page, or even at the bottom of the article, but it certainly seems to fit the bill – it’s information about its section, containing author name, links to related documents (comments) and the like. There’s no reason that you can’t have more than one footer on page; the spec’s description says "the footer element represents a footer for the section it applies to" and a page may have any number of sections. The spec also says "Footers don’t necessarily have to appear at the end of a section, though they usually do."

Comments

I’ve marked up comments as articles, too, as the spec says that an article could be “a user-submitted comment”, but nested these inside the parent article. The spec says

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a Web log entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the Web log entry.

These are headed with the date and the time of the comment and name of its author—if you want, you can wrap these in a header, too, but to me it seems like markup for the sake of it.

Times and dates

Most blogs, news sites and the like provide dates of article publication.

Microformats people, the most vocal advocates of marking up dates and times, believe that computer-formatted dates are best for people: their wiki says “the ISO8601 YYYY-MM-DD format for dates is the best choice that is the most accurately readable for the most people worldwide, and thus the most accessible as well”. I don’t agree (and neither do candidates in my vox pop of non-geeks, my wife, brother and parents).

I do agree with the microformats people that hidden metadata is not as good as visible, human-readable data and therefore elected not to use the pubdate attribute of article.

Therefore I’ve used the HTML 5 time element to give a machine parsable date to computers, while giving people a human-readable date. Blog posts get the date, while comments get the date and time.

The spec is quite hard to understand, in my opinion, but the format you use is 2004-02-28T15:19:21+00:00, where T separates the date and the time, and the + (or a -) is the offset from UTC. Dates on their own don’t need a timezone; full datetimes do. Oddly, the spec suggests that if you use a time without a date, you don’t need a timezone either.

There’s considerable controversy over the time element at the moment. Recently one of the inner circle, Henri Sivonen, wrote that it’s for marking up future events only and not for timestamping blogs or news items: “The expected use cases of hCalendar are mainly transferring future event entries from a Web page into an application like iCal." This seems very silly to me; if there is a time element, why not allow me to mark up any time or date?

The spec for time does not mention the future event-only restriction: "The time element represents a precise date and/or a time in the proleptic Gregorian calendar" and gives three examples, two of which are about the past and none of which are "future events". Although the spec doesn’t (currently) limit use of the element, it does limit format to precise dates in "the proleptic Gregorian calendar". This means I can mark up an archive page for "all blog posts today" using time, but not "all July 2008 posts" as that’s not a full YYYY-MM-DD date. Neither can you mark up precise, but ancient dates, so the date of Julius Ceasar’s assassination, 15 March 44 BC is not compatible.

I don’t expect this to be resolved. If you think as I do, feel free to mail the Working Group to express your feeling!

Hopefully, this brief article (geddit?) has given you a quick overview of how to use some of the new semantic elements. Let me know what you think!

Share and Save:

Designing a blog with html5 originally appeared on HTML5 Doctor on June 30, 2009.

HTML5 Doctor » Bruce Lawson

Video: the track element and webM codec

WebM video format

Related Posts:

The nsfw element

Related Posts:

The time element (and microformats)

The fly in the ointment

Incorporating the pubdate attribute

Hello, summary and figcaption elements

Related Posts:

The section element

Any level of heading

What about main content?

Rules of thumb for using section

Related Posts:

It’s bug report time!

Related Posts:

“Block-level” links in HTML5

Bruce Lawson voted sexiest man on Earth

Bruce Lawson voted sexiest man on Earth

Shiny, but not new

Related Posts:

HTML 5 + XML = XHTML 5

Related Posts:

Designing a blog with html5

Setting the DOCTYPE

Using some new structural elements

New form attributes

A note on screenreaders and HTML 5

Laying out the new elements

IE layout

Firefox 2 and Camino 1 layout

What’s the point of those new structural elements?

Further refining the HTML 5 structure

The blog home page

Anatomy of a blog post

Data about the article

Comments

Times and dates

Related Posts:

Incorporating the `pubdate` attribute

Rules of thumb for using `section`