Chapter Eleven: HTML5
What is HTML5?
As we saw in Part I of this book, by around 2000, most major forces in the web development community considered XHTML to be the future of HTML. Much of the first two editions of Jeffrey Zeldman’s groundbreaking Designing with Web Standards, for example, focus on XHTML and pay little attention to HTML. But even though many developers, myself included, expected XHTML to be the future of HTML and accordingly adopted XHTML syntax, browser support for XHTML was slow in coming. In particular, browser support for XHTML 2—the W3C’s planned successor to HTML/XHTML—was almost nonexistent, and the W3C has recently ended the development of XHTML 2. As a result, web markup languages stagnated for several years.
In the meantime, revolutionary changes were occurring on the web. The widespread adoption of broadband brought fast connections to many web users, and as a result, streaming audio and video became increasingly commonplace. The rise of blogging brought the concept of user-generated web content to the mainstream. Faster computers and browsers, combined with Microsoft’s innovative XMLHttpRequest, made web applications—or “web apps”—a reality.
The web was no longer made up of static pages alone. Applications such as Gmail, Google Maps, and countless others brought sophisticated, desktop-style functionality to the web browser—functionality exemplified by apps such as 280 Slides (www.280slides.com), a rich, entirely browser-based presentation application, and Mozilla Lab’s Bespin code editor (bespin.mozilla.com).
HTML, however, remained rooted in the concept of a web page—which isn’t entirely surprising, given that it began life as a document markup language. Meanwhile, the W3C continued its work on XHTML 2, but its work was criticized by many developers and browser-makers as insufficiently attuned to the needs of real-world web development. In 2004, Mozilla and Opera jointly presented the W3C with a more pragmatic proposal for the future of HTML. As the History section of the current HTML5 specification notes, their proposal was “rejected on the grounds that the proposal conflicted with the previously chosen direction for the Web’s evolution” (www.w3.org/TR/HTML5/introduction.html#history-0).
In response to this assessment, employees of Apple, Opera, and Mozilla formed an open consortium to address concerns about this “chosen direction” and to develop an alternative specification for the future of HTML. (Microsoft employees declined to participate, citing concerns about the consortium’s intellectual property policy.) Thus was born the “Web Hypertext Application Technology Working Group,” or WHATWG. WHATWG’s specification, originally called “Web Applications 1.0,” continued to evolve, and in 2007, the W3C adopted it as the basis for a new version of HTML to be called HTML5.
As of mid 2009, with the formal termination of the W3C’s XHTML 2 working group, HTML5 stands as the likeliest future of HTML. However, some concerns about HTML5 remain, including:
• Its lack of extensibility. As was the case with HTML4, HTML5 provides no way to extend its semantics outside of the development of an entirely new version of HTML.
• Its lack of integration with other web technologies, such as RDFa.
• Its perceived over-emphasis on documenting current browser behavior, rather than on the future of the web.
As a result, the current HTML5 specification will almost certainly undergo significant change before it is finalized. However, it also should be noted that there is considerable support for the HTML5 project among web developers, browser makers, and the W3C. In this chapter, we’ll focus on aspects of HTML5 that are already supported in browsers—and that are least likely to change.
Key Features of HTML5
HTML5 is designed to be as useful as possible in actual web development practice. It is meant to be evolutionary (rather than revolutionary, like XHTML 2), to be backward compatible with older versions of HTML and older browsers, and to solve real-world problems.
The WHATWG’s HTML5 project encompasses much more than the syntax and semantics of a markup language. In this chapter, we’ll focus primarily on HTML5’s syntax and semantics, but it’s worthwhile to take a moment to get a sense of the significance and scope of the HTML5 project. The following are some of the areas the project covers, a few of which have subsequently been spun out into their own specifications:
Error Handling
HTML5 aims to standardize error handling so that all browsers respond to errors in HTML5 markup in the same way. This is a very significant step away from XHTML’s XML-based error handling.
The canvas Element
First implemented in Safari, the canvas element (which we look at in detail in Chapter 16) is a two-dimensional drawing context that lets developers use JavaScript to render lines, shapes, curves, and other graphical objects in a web page or application.
Local Storage
New in HTML5, this feature lets browsers securely store and access arbitrary amounts of data on the client, which lets web applications run even when a user isn’t connected to the web, and improves performance. Essentially, this is like a much more powerful version of cookies.
“Threaded” JavaScript with Web Workers
JavaScript is a single-thread environment, which means that when a computationally intense script is running, a page is essentially unresponsive to user input. There are methods of using timers to simulate the concept of “threads,” a feature of most modern programming languages that allows functions to execute in parallel, but these methods can be difficult to use. HTML5 originally introduced the concept of “web workers” (a somewhat confusing name), which is now its own W3C specification. A web worker is a thread or function that can run independently of other functions, allowing for more than one JavaScript function to run at a time or for time-intensive functions to run without disrupting the responsiveness of a page.
Multimedia Support
HTML5 foresees native support of video and audio in the browser, via the new video and audio elements, which we’ll take a look at a little later in this chapter.
Location-Aware Web Applications with Geolocation
Now its own specification, and with implementations in Firefox 3.5, betas of Opera 10, and Safari in the iPhone 3.0 version, the W3 Geolocation API, originally part of HTML5, allows developers to query the browser for the user’s location. This capability makes possible a huge range of location-aware services that have until now been possible only with native applications on some mobile platforms.
User-Editable Pages
Through its contenteditable, draggable, and spellcheck attributes, HTML5 makes it much easier for users to edit web pages, with far less work by developers.
As you can see, HTML5 is a huge undertaking, and there’s a great deal more to it than this brief look reveals. But many of the features discussed here and in the rest of this chapter are usable in one or more current browsers; many commercial developers, including Google, already use aspects of HTML5 today. Perhaps even more importantly, HTML5 has the support of browser developers—something XHTML 2 never received. As a result, it seems likely that many of the false steps of XHTML 2 won’t be repeated with HTML5.
Differences from HTML4
To get into the details of HTML5, let’s begin by taking a look at how it differs from HTML4.
While HTML5 is designed to be backward compatible with HTML4, it actually has two “flavors” of syntax—an HTML syntax and an XHTML syntax—so you can continue to use HTML5 with whichever syntax you’re most comfortable with.
HTML5 also allows developers to use two XML languages—MathML, a markup language for mathematics, and SVG, a markup language for vector graphics we’ll cover in the last chapter of this section—directly within HTML markup.
Additionally, HTML5 introduces several new HTML elements, the most useful of which are detailed in the “Headers, Footers, Sections, and other New Structural Elements in HTML5” section of this chapter. Some of the characteristics of current HTML elements have also changed in HTML5. Anchor elements (<a>), for example, can now contain any other elements, not just inline elements as is the case with HTML4 and XHTML 1. So it’s now possible to link, say, the entire header of a page to a URL simply by putting it within an anchor element. As you might expect, some elements deprecated in earlier versions of HTML, such as font, center, u, and non-iframe frames, are not part of HTML5, though other elements that might be considered presentational, such as <i>, remain in the language. The specification also includes a number of changes to the DOM, and much more besides.
When it comes to everyday implications for developers, here are some of the most significant changes you’ll see in HTML5.
Declaring a DOCTYPE
Described in the specification as a “mostly useless, but required” header, a DOCTYPE is required in HTML5 documents, mostly to ensure compatibility with older browsers that respond to missing DOCTYPEs by rendering such pages in “quirks” or “non-standards” modes. The required DOCTYPE is about as simple as it can be. At the top of an HTML5 document we simply use the following:
<!DOCTYPE HTML>
The DOCTYPE is case-insensitive—it can be uppercase, lowercase, or a mix of cases.
Headers, Footers, Sections, and other New Structural Elements in HTML5
As we’ve mentioned, HTML5 introduces many new elements. In the rest of this chapter, we’ll look at several new structural elements of HTML5, along with elements related to embedded content, such as video and audio.
The logic of the new structural elements in HTML5 comes from research into common ways in which current web documents are marked up. Some of the most common class and id values and most commonly used “patterns” of markup that web developers will instantly recognize include “header,” “footer,” and “nav” (or some other variation of the term “navigation”). HTML5 uses many of these common patterns and terms for new elements.
header
Many web pages include an area at the top of the page that displays identifying information about the page and site, often including an organization’s logo and name, and often also navigation, for example, the different subsections of the site. HTML5 introduces a new element, header, for this type of content—though in HTML5, header elements don’t have to appear at the top of a page, as we’ll see in a moment.
Header elements are governed by a number of syntax rules: They must contain at least one heading (h1 to h6) and must not contain a section element, another header element, or a footer element. Unfortunately, the nav element is a kind of section, so the header can’t contain nav elements. This is a significant challenge in the real world, as many page headers contain navigation systems. Although the most recent editors’ draft of the HTML5 specification has relaxed this requirement, as of this writing, the current official draft specification still prevents nav elements from being contained within a header. It’s to be hoped that the relaxation of this constraint will become a permanent part of the HTML5 specification.
Content Elements
HTML4 and XHTML 1.x offer few ways of grouping together the content of a page. There’s the p element for paragraphs, but for larger logical chunks of information—chapters, for example—we must use divs. And, as we saw in Chapter 4, a div is simply a block container with no intrinsic semantic connotations. HTML5 introduces several elements that allow developers to group and semantically identify content.
section
Paragraphs of information are typically grouped together into larger sections, such as a book chapter, a magazine or newspaper article, or a blog post. HTML5 provides the <section> element for grouping together content—paragraphs, images, headings, and so on—to form a larger logical unit.
section elements may contain a header and a footer, and indeed can contain any element that can be contained inside the body of an HTML5 document. They can also include more specific information, or metadata, about a section using the class or id attribute as appropriate. For example, an academic paper often includes an abstract, so we could mark that up as <section id="abstract">. A book usually has many chapters, so we’d likely mark up chapters using <section class="chapter">.
The section element is not designed to be a replacement for the div element, which is still part of HTML5; section elements should only be used when they’re semantically appropriate. For other forms of content groupings, div is still the appropriate element to use in HTML5.
article
HTML5 also offers specific types of sections, one of which is the article. Articles are sections that can logically exist independently from the page in which they occur. For example, a single page on a newspaper or magazine website might contain several independent articles. By contrast, the chapters of a novel marked up as a single HTML document do not stand independently from the containing page, and so are more appropriately marked up as section, rather than article, elements. Other forms of content that might be marked up with the article element include blog posts, dictionary and encyclopedia entries, and short stories.
Headings in section and article Elements
HTML4 headings have a significant limitation: there can be, at most, six levels of headings within a given document. There are certainly documents for which this is an unrealistic number: documents such as articles of legislation often require many more levels than six, and heading levels are fundamentally important to the nature of legislation (they are used in legal citation).
HTML5 addresses this deficiency by allowing (and encouraging) each section to begin numbering its headings from level 1 and “strongly encouraging” that each section be associated with a single heading. This single heading should either be an h1 (that is, each section, no matter how deeply nested within other sections begins with a heading of level 1), or the level of the single heading of each section should match the level of nesting of the section. This is outlined in the specification at www.whatwg.org/specs/web-apps/current-work/#headings-and-sections.
As you can see, HTML5 offers a much more sophisticated (and, arguably, overly complex) document structuring model than HTML4. In HTML4, a single parent element—usually the body or a div—typically contains headings and paragraphs as its direct children. The structure of such documents is revealed only by its numbered headings. In HTML5’s sectioning model, it’s really the nesting of section elements, rather than heading levels, that reveals the structure of the document.
Here’s what the structure of this chapter might well look like in HTML4:
In HTML5, each heading is associated with a section, and we can explicitly reveal the document’s structure via the nesting of these sections. Here’s how the same document might be marked up in HTML5:
Or, we can simply continue to number headings as we would in HTML4, as if the section elements weren’t there:
nav
Just as “header” (or some variation of that term) is one of the most commonly used class and id names in HTML, “navigation” (or some variation, such as “nav”) is similarly popular. HTML5 introduces the nav element, to mark up “a section of a page that links to other pages or to parts within the page.” The specification continues, explaining the element is not intended to be used to mark up all groups of links on a page: “only sections that consist of primary navigation blocks are appropriate for the nav element.”
One drawback of the nav element is that developers often mark up navigation in HTML4 and XHTML as a list of links—after all, site and page navigation is usually made up of a list of links. Because nav is a kind of section, however, if we wish to continue using lists for navigation markup, we must wrap our lists in a nav element. For example, we may currently use something like the following for our navigation:
To continue using this list for our navigation links in HTML5, we’d wrap the whole thing in the nav element, like this:
aside
Articles and stories often feature sidebars, which contain related secondary content. HTML5 calls these “asides” and provides the aside element for marking up this kind of content. We’ll see asides, along with other new HTML5 elements, in action in a moment.
figure
HTML4 offers a single way to include images in markup, and CSS provides background-image and other ways of adding images as decoration, but not as part of the document itself. In real life, however, images appear in documents in different ways and for different reasons and are often accompanied by captions or descriptions. HTML5 provides the figure element for these kinds of images.
A figure in a book or article often includes an image and a caption. Together, the image and caption comprise a figure element in HTML5 (though the caption element is not technically required.) In HTML4, we’d likely mark up this sort of content as follows:
In HTML5, we can use the figure element in place of the div, and then go a step further using the legend element—which is used in HTML4 to caption form elements—in place of the span element in our example. Rather than invent a new element for this purpose, HTML5 reuses an existing element of HTML with similar semantics. Putting these components together, our HTML 4 example could be marked up in HTML5 using the following markup:
The order of legend and image can also be reversed.
Somewhat confusingly, the figure element can in fact be used for more than just images. The specification states that the element is for content that is “self-contained and is typically referenced as a single unit from the main flow of the document.” It can thus be used to mark up illustrations, diagrams, photos, code listings, and so on, that are referred to from the main content of the document but that could, without affecting the flow of the document, be moved away from that primary content, such as to the side of the page, to dedicated pages, or to an appendix.
footer
Another common markup and page design pattern is a page footer, which typically contains fine-print content such as copyright notices, privacy policies, contact details, and so on. As you might guess, HTML5 introduces a footer element for this kind of content. Just as headers can be used in places other than the top of a document, footers don’t appear only at a document’s end—they may appear at the end of sections or articles as well. Blog posts often conclude with details such as the author’s name, the date and time of publication, tags for the post, and so on, and in HTML can all be sensibly marked up in a footer element.
Footers also need not appear at the very end of their containing element—for example, in a blog post or article, they might be followed by comments. For some time, the HTML5 specification stated that footer elements could not contain headings, header elements, sections, or other footers, which was something of a problem, since many web page footers include detailed content structures. Happily, these restrictions have been lifted in the current and (we hope) final draft of HTML5.
An Example HTML5 document
Even if you have not yet used the new elements of HTML5, the concepts behind them will be familiar to you from HTML4 or XHTML. Let’s take a look at a fairly standard web page design and see how these new elements might be used.
At the top of figure 11.1 is a header element. In figure 11.2, we see that within the header is also a nav element for site-level navigation.
11.1 A perfectly ordinary-looking page—but beneath its smooth surface lurks HTML5
11.2 The header of our HTML5 page
The markup for this element looks like this:
This markup should be nearly self-explanatory. One thing worth noting is that our upcoming events are in a div, not a section, because headers cannot have sections as descendents. (Remember, too, that we need at least one heading in a header element.)
The main content of the page, between the header and the footer, is made up of two parts: the content of the page, which will be on the left, and a collection of tools and navigation aids, which will be on the right. The content on the left can be sensibly marked up as a section, as it is “a thematic grouping of content.” The content on the right really doesn’t conform to that definition, so it probably should be marked up as a div element, as it would be in HTML4.
Turning to the content in figure 11.1, we can see a pie chart with a caption. We know that HTML5 has the figure element for this kind of content, which we’d mark up like this:
The main text of this section [11.3] includes two separate sections.
11.3 The main content of our HTML5 page
Each section comprises a heading and one or more paragraphs. Although sections can contain headers, the structure of these sections is simple, and the header would only be there to contain a single heading, so in this case we won’t wrap the headings in a header.
In more complex sections of a page, such as in the content of a blog post, the header element may be appropriate. In figure 11.4, a specific post at the site has not only a title heading, but also category, author, date, and other information. This would be sensibly marked up inside a header element inside the section element. What’s more, since the section itself is an article that could be meaningfully reproduced elsewhere as a whole, this post would be most appropriately marked up as an article. Meanwhile, the sections in our full-page example are part of a larger whole, and as such aren’t appropriately marked up as articles.
11.4 A section in our HTML5 site
The first of these sections contains a “pull quote,” which can be marked up as an aside element. So the markup for the first section in our full-page example would look something like this:
We’ve chosen to mark up the heading as a level 1, but it would equally be appropriate to mark it up as a level 3, since the section is nested inside the body, and then inside the section that contains the main content of the page—in other words, it’s nested three levels deep.
On the right of the content section are tools such as the search field, navigational aids such as the tag cloud, and links to related material. As noted earlier, this doesn’t really conform to the definition of a section, and so the div element remains the most appropriate way of marking it up. However, the tag cloud is primarily a way of navigating through a large amount of information, so it would make sense to mark this up using a nav element.
At the bottom of the page, we have what most of us will recognize as a footer [11.1]. But we have a problem. HTML5 footers can’t contain sections or headings. Our “footer” contains elements that would be best marked up as headings, and quite possibly sections as well, so rather than marking up the content that appears to be a footer using a footer element, we’ll reserve that element for the “fine print” content:
As you can see, HTML5 provides these new elements for very commonly used markup patterns, which will for the most part be familiar to developers with experience marking up web documents. Even those with limited experience of markup should find most if not all of these elements conceptually familiar from years if not decades of reading.
The key to good HTML5 markup, just as it is to more traditional HTML markup, is to understand the semantics of the document you are marking up, and using the most appropriate elements (and attributes) for this markup. HTML5 extends the range of semantics developers can use to mark up their content, and these extended offerings are based in part on extensive research on existing common web design and markup patterns.
Video, Audio, and Other Embedded Content in HTML5
Embedded content, including video and audio, has never been one of HTML’s strong points. The nonstandard embed element has slowly been replaced by the object element of HTML4, though it continues to be widely used for embedding all kinds of plug-in–based content. One drawback of the object element is its generic nature. It’s designed for embedding anything: an image, Flash or Silverlight content, even other HTML documents, and, of course, audio and video. Using a single element for all embedded content makes it difficult for browsers to offer playback controls that are specific to video or audio content, and to provide other media-specific features (such as a placeholder image that makes sense in the case of video, but less so for other kinds of content).
The embed and object elements are both designed for content rendered by plug-ins such as Flash. In HTML5, video and audio get their own elements: video and audio, respectively. Unlike embed and object, these elements allow for:
• Native browser controls, such as play and pause
• Multiple source files, allowing different resources to be fetched depending on browser support for different video or audio formats, or media queries
In addition, like object (but unlike embed), video and audio elements make it easy to add “fallback” content for browsers that don’t support the element.
So, why have both the embed and object element been included in HTML5, particularly as embed has never been, until now, a standardized part of any HTML specification? The authors of the HTML5 specification have decided that since embed is almost as widely used as the object element, it should be standardized. Regardless of the merits of that argument, I’d suggest using the object element for plug-in content that is not strictly video or audio (Flash-based interactive elements, for example), and the video and audio elements for video and audio content, along with a fallback strategy for browsers that don’t support these elements.
Video
The developers of HTML5 initially planned to specify a standard video format, or codec (“coder-decoder”), that HTML5–supporting browsers would all support, thus enabling plug-in–free (“native”) video playback in these browsers. Unfortunately, due to concerns from browser developers about the patent status of almost every video format, no consensus could be reached regarding such a format or formats. As a result, even though the video element is part of HTML5, no specific standard video format is part of the specification. This is a concern for some developers, but historically, the HTML specification has never specified which image formats browsers should support. At the time of this writing, Firefox 3.5 has native support for the Ogg Theora codec, but other browsers require the appropriate plug-in to play back video content (while Firefox 3.5 requires a plug-in to play content in formats other than Ogg). All other browsers require plug-ins for playing video.
Even though there’s no standard video format that we can rely on all browsers to support, the video element of HTML5 is still a significant step forward. Let’s put it into practice.
There are two ways we can specify the source of the video that the element embeds. A simple way is to use the src attribute, with a URL that identifies the video file: <video src="path/to/src.ogg"></video>.
Of course, we may well want to provide any number of different video formats to give a browser the best chance of successfully playing the video content. We can do this using source elements inside the video element. By themselves, source elements do nothing, but inside a video element, they specify one or more source files for the browser to display. (Note that if the video element has a src attribute, the source elements are ignored.)
source elements also specify their source file using a src attribute. In addition, we can use a mimetype attribute to tell the browser what file format we’re using (for example, MP4).
Like link elements, source elements may take a media attribute with a media query value, to specify different sources for different media. For example, we might offer a low-resolution encoding for low-resolution screens, a 16:9 format video for devices with a 16:9 aspect ratio, and so on. But the src attribute of a source element is all that’s actually required. (We’ll cover media queries in detail in Chapter 14.)
In the following example, we’ve provided two options: the widely supported mp4 format and the Ogg format:
Where more than one source element is provided, a browser will use the first one whose content type it supports and will ignore the rest.
The video element also includes many attributes that provide the kind of functionality previously available only via plug-ins, such as autoplaying, looping, and the drawing of controls. The element can take the following attributes:
• poster—This attribute provides an image to be used while no video is available (for example, while a video is downloading or pre-buffering). It takes a URL of an image, such as a PNG, which can be used, for example, to display the first frame of the video while that video is still loading.
• autoplay—This attribute tells the browser to begin playing the video as soon as possible.
• loop—The loop attribute tells the browser to play the video repeatedly from the beginning.
• controls—This attribute tells the browser to draw its own controls (such as play, pause, and fast-forward) for the video content.
• width and height—These elements specify the respective width and height of the element. The browser can also use the intrinsic dimensions of the video, but it will only be able to determine these after downloading some of the video file, so specifying width and height is recommended.
If we want our video to display an image while loading, to autoplay when loaded, and to provide the user with browser-drawn controls, we’d add these attributes:
The autoplay, controls, and loop attributes are all Boolean attributes. We saw earlier that in HTML4, it’s optional to provide values for such attributes—so in HTML4, we can specify an autoplay attribute as either autoplay="autoplay", or simply as autoplay. In HTML5, only the first of these forms is valid. In HTML5, where a Boolean attribute is present in the opening tag of an element, the value of the attribute is true. Otherwise, it is false.
Fallback Content
Unlike the empty embed element, but like the object element, the video element can contain content. source elements make up the primary content of the video element, but we can also provide fallback content for browsers that don’t support the video element. The simplest way we can do this is to add some text that displays only when the video element isn’t supported:
Of course, if possible, we should try and use a complementary method for displaying video on older browsers. As we saw in Chapter 3 of this book, the HTML4 approach is to use the object element, and we also know that the object element allows for fallback content. So we could use object as fallback content to display video in browsers that support it, and we could also use simple fallback text for all other browsers:
Audio
HTML5 also has an audio element, which is very much like the video element—the only significant difference is that the audio element lacks a poster attribute. Again, the source of the audio is specified either with the src attribute or with one or more source elements. Fallbacks to the object element of HTML4 or text content are specified in the same way, as are autoplay, loop, and controls attributes:
Video and Audio Browser Support
In mid 2009, only Firefox 3.5 and Safari 3.1 and higher had support for the audio and video elements in final versions of the browsers. Firefox’s support is presently limited to two audio formats, Ogg Vorbis and WAVE, and one video format, Ogg Theora. In addition, Firefox requires that the audio or source elements have a type attribute. Importantly, even if Firefox 3.5 has a plug-in that enables the playback of another format such as QuickTime, the browser won’t play this content with the audio or video element, though it will play it with the object element. Safari’s support is broader than Firefox’s. If it has a plug-in to play back the content format, it will play video or audio elements in that format.
One noted problem with video or audio elements in Safari (at least until version 4) is that the browser begins downloading all of the content embedded with these elements at once—a behavior that can soak up a lot of bandwidth and affect browser performance. This could be a problem when a large number of audio and video elements are on a page.
Video and Audio Accessibility
As we move toward a richer web, we must continue to consider accessibility in our design and development practices. The existence of the fallback feature of audio and video is not designed as an accessibility feature but as a mechanism that provides multiple ways to embed content and a means of notifying the user when none of these are supported. This simple fallback mechanism is in no way designed to replace methods of providing accessible audio and video via the use of captioning and transcription. (Audio and video captioning and description are beyond the scope of the book, but they are important to consider whenever you use audio- and video-based content.)
HTML5 Support in Browsers
All these new HTML5 features might sound great in theory, but in practice, can we use them in browsers today? By and large, the answer is yes...but a few challenges remain.
IE7 and Earlier Versions of Internet Explorer
In Safari, Firefox, IE8, and Opera, we can style section, aside, nav, and other new elements using CSS. But in IE7 and older, we can’t out of the box. These older versions of Internet Explorer simply ignore CSS like this:
Even adding classes to the elements—for example, <section class="section">—doesn’t let us style them in IE7 and older versions. In essence, the new elements are invisible to CSS in these browsers.
Since these browsers are still used by a majority of web users in 2009, and will likely be used by many for some time to come, does this mean we can’t use these new elements? Happily, no. We can in fact use and style these elements, though the method we’ll use is imperfect. There is a JavaScript workaround for IE7—and a more aggressive approach for IE6 and older versions of IE—if you must support these browsers.
Workarounds for IE
Remy Sharp has developed a JavaScript-based approach that involves nothing more than linking to a small JavaScript file, HTML5.js, available at remysharp.com/downloads/html5.js.
This script tricks IE7 into seeing HTML5 elements, and for IE6, replaces the elements with divs or spans and classes with values that match the name of the HTML5 element that was converted. This dual approach means that for IE6 compatibility, we’ll need to replace CSS rules like this one:
Dean Edwards, the man behind the IE7 JavaScript library, has also created a JavaScript library that enables the use of HTML5 features in browsers that don’t support HTML5. It’s available here: code.google.com/u/dean.edwards/updates.
A Caution
JavaScript-based solutions are far from ideal. Many corporate environments disable JavaScript for security purposes, and for site visitors who use IE6 and IE7 without JavaScript, your HTML5 elements will appear unstyled. The JavaScript methods also create considerable complexity when it comes to styling pages if your project requires backward compatibility with IE6.
Validating and Serving HTML5
HTML5 can be validated using an experimental validator at validator.nu. (This is presently the only way in which HTML5 can be validated.) Documents that use the XHTML5 syntax can be checked for “wellformedness” using any XML validator.
Confusingly, the two different syntaxes of HTML5 (HTML and XHTML) must be served in two different ways. HTML5 documents that use the HTML syntax must be served with a mimetype of “text/html,” whereas XHTML syntax documents must be served as “application/xml” or “application/xhtml+xml.” (If XHTML documents are served as “text/html,” browsers are to treat them as HTML, not as applications of XML, even if they are valid XHTML documents.) For the most part, the distinction won’t have any practical impact on developers; browsers will almost certainly treat XHTML5 documents served as “text/html” as HTML5 documents.
Should I Be Using HTML5 Today?
It’s certainly possible to use HTML5 markup with today’s browsers, though there are significant challenges when it comes to Internet Explorer. HTML5 is also a specification in a state of flux, and doubtless some of what you’ve read in this chapter will be out of date before HTML5 is finalized, despite our focus on the most stable aspects of the specification. As even the developers of HTML5 have stated, HTML5 should be used with caution. That said, HTML5 will become increasingly well supported over the coming years, and as a practicing web developer, you’ll want to know how to use it. As the web becomes an increasingly application-based medium, HTML5 will play an ever-more important role, so developers who focus on web applications should investigate HTML5 sooner rather than later.
Furthermore, although we’re unlikely to see HTML5 used as the main markup language for highly trafficked sites in the short term, Google’s recently announced Wave communications application uses HTML5 extensively—in particular for its application-focused aspects like offline storage—so the language is far more than simply an experimental plaything, even today.
Finally, it’s worth noting that HTML5 is unique in terms of its development at the W3C. Most web standards are developed by a small, closed group of experts. The HTML5 development process, however, is much more open, and its developers actively encourage input. For details on how to participate, see blog.whatwg.org/help-us-review-html5.