We're going to start right at the beginning. In this chapter, we'll look at the history of HTML, to understand where we've come from and where we're headed. Next, we'll explore the new features that HTML5 brings to the table, detailing how and when they should be used. We'll then deconstruct an example web page created using HTML5 to better understand how it could be applied in authentic situations. And lastly, we'll clear up some of the confusion surrounding HTML5 and other new web technologies. Ultimately, this chapter will give you a better understanding of HTML5, providing you with the knowledge necessary to progress further into the book.
In December 1997, the World Wide Web Consortium (W3C) officially announced HTML 4.0 as a W3C recommendation.[1] HTML 4.0 was very different to its predecessors, and brought with it new and exciting functionality, like cascading style sheets (CSS) and client-side scripting. These features alone dramatically changed the way people created websites, moving away from the reliance on tables for presentation, and allowing for dynamic websites using scripting languages like JavaScript. Before this, HTML was mostly a static and limiting environment that lacked most of the features you would normally now associate with the Web: it was basically just text and images.
HTML 4.01 was released in December 1999, but didn't bring with it any major new functionality.[2] Its main purpose was to correct some errors in the specification and apply a few minor changes. After all, by this time HTML 4 had only been around for a couple of years, so there wasn't much need to muck around with it. For the next five years things chugged along fairly smoothly. During that time there were attempted updates to CSS, XHTML 1.0 was released, and the infamous browser Internet Explorer 6 was launched. It was in 2005 when the draft specification for Web Applications 1.0 was released, by the Web Hypertext Application Technology Working Group (WHATWG),[3] that the story begins to get interesting.
Both HTML 4.0 and XHTML 1.0 (with 2.0 in draft) were created before today's concepts of blogs, online shops, and forums really took hold. The problem with these versions was that they were built to mark up static documents, which blogs and online shops are not — they are essentially applications. Web Applications 1.0 was created to solve this problem — to provide an extension to HTML that accommodated these types of websites by adding new elements (the tags used to mark up content) and functionality. By 2008, Web Applications 1.0 blossomed, was adopted by the W3C, and turned into the first draft of the HTML5 specification. It introduced a raft of new and powerful features that we'll discuss in more detail throughout this book.
So after a brief glimpse into the past, we arrive at the present. HTML5 is now in a working draft form and is changing as we speak. It's technically unfinished and will stay that way for some time to come; a working draft is one step above a draft, but it's only the third step out of six.3 However, the good news is that parts of HTML5 are already being built into a variety of browsers, allowing us to use these exciting features right now. There is really no reason for any decent Web designer or programmer not to look at HTML5. It is, put simply, the future of the Web. Do you really want to be left behind while everyone else is having such good fun?
As we've discussed, HTML5 has been created to scratch the proverbial itch. But what exactly is the itch? And how does HTML5 scratch it? Let's find out.
In HTML 4.01, and earlier versions, we know that there was a document-oriented approach to things. The Web was originally created to display and share scientific documents. That concept of documents continued through the Web's early life, albeit with more generic information rather than just scientific data. However, in the years after HTML 4.01 there began a rise in dynamic websites and online applications, supported in part by the adoption of Adobe Flash and other third-party plugins that allowed you to create applications full of rich, interactive media. Content management systems (CMS) and services like WordPress started to crop up, offering anyone the ability to create a blog or manage large quantities of content using templates. Flickr allowed for the sharing of photographs, with YouTube doing the same for video. And, once faith was restored in the Internet after the dot com bubble went pop, online stores and auction sites started cropping up all over the place, selling items from books to the unwanted crap in your attic. The Web was becoming less and less static, with more content being user-generated and inherently dynamic.
In essence, the Web grew away from its roots in individual static documents, focussing now on large quantities of dynamic data being displayed using templates. It would be wrong to describe the Web in its entirety using this definition, of course, but it highlights a fundamental shift in how the Web was being used. The problem was that HTML was never built to deal with this kind of use; it was built to deal with fairly strict types of document-based content (paragraphs, images, headings, and so on). Anything more exotic, like media or CMS content, required the use of external plugins, like Adobe Flash, and ill-fitting code. Something else was needed that brought HTML up to speed, allowing it to accommodate media and allow for better, more semantic code.
HTML5 brings with it a massive amount of improvements over the old document-oriented Web. New elements have been created to mark up dynamic, templated content. Other elements have been created with the sole purpose of ending our reliance on external plugins to experience audio-visual content. These elements alone solve many of the problems, but the W3C (with credit to the WHATWG) hasn't stopped there. For example, form validation, previously something only achieved via JavaScript, is also part of HTML5. With practically all user-generated content on the Web being created, in part, using some kind of input form, validation within the browser is more important than ever.
As well as HTML5, and intrinsically tied to its development, are other technologies that hope to solve related issues. One such example is the Web today being much more mobile than it was 10 years ago — it's reckoned that 95% of mobile phones have some sort of Internet browser.[4] With more and more people wanting to access content specific to their location, would it not make sense to implement geolocation within the browser? These, among others, are technologies that are being created alongside HTML5 to scratch the itch once and for all.
HTML5 introduces a whole host of new functionality, covered in page after page of specification on the W3C and WHATWG websites. This book has been written to give you a foundation for understanding the specification; it will take you through the important new features of HTML5 in detail — in plain English.
Note
It's not easy to define exactly what is and isn't HTML5. The specification is in a state of flux at the moment, particularly as it's split between the W3C and WHATWG. Also, many features that started life as HTML5 have since grown up and moved into their own separate specifications, like geolocation and scalable vector graphics (SVG). The definition of HTML5 in this book is based solely on the specification found at the WHATWG.[5]
As we'll discuss at the end of this chapter, many people lump other technologies into the HTML5 category (like CSS3) that are not actually part of the specification. Fortunately for us, the canvas element is firmly attached to the HTML5 specification, so we need not worry about referring to it as HTML5.
By now we already know that HTML5 brings with it a variety of new elements, both for content structure and media. HTML5 also brings with it a raft of new and improved features, like with forms. But what are these new features, and what do they do? You could write an entire book covering everything new in HTML5, but the next few sections will provide an overview of the most interesting and important features.
Note
Explaining every single detail of HTML5 is beyond the scope of this book. If you'd like to learn more about the new features, then have a read through the HTML5 specification. It can be a bit of an eyeful, but it's well worth it if you want to truly understand how everything works.
It's safe to say that every website ever created uses structural and content elements in one way or another. From paragraphs (<p>) to divisions (<div>), these types of elements are the bread and butter of the Web. However, the problem with HTML as it existed previously was that it didn't support content that falls outside of the concept of documents. Fortunately, HTML5 introduces a huge list of new elements that aim to solve this issue and give content much more semantic meaning.
The new structural elements in HTML5 give us a whole host of ways to describe the various sections within our Web pages. Normally you would be limited to using copious amounts of div elements with a splattering of span elements for good measure. Not anymore! We now have access to elements like section, header, hgroup, footer, nav, article, and aside. Each of these new elements has a unique purpose to help differentiate the most common areas on a modern Web page.
Arguably the div of the HTML5 world is the section element. The HTML5 specification describes it as a generic section of a website. Specifically, its purpose is to group content thematically; that is, grouping content into areas that are distinguishable from the rest in theme or focus. An example would be chapters in a large body of writing, or areas on the same page of a website, like an introduction, gallery of portfolio work, and a contact form.
Note
The important rule with the section element is not to think of it as a replacement for the div element. A section is to be used for defining specific, distinguishable areas of a website. A div element should be used only as a last resort, usually when no other element would make sense.
Whether it holds a logo or the name of a company, most websites have a header of some sort. Before now, a header, like most areas of a website, would likely be constructed using a div element, or some other generic element not suited to the task. The new header element essentially saves our sanity by allowing us to define a specific area of a website that contains headings, logos, navigation, and any other content you'd normally associate with a header. You can also have more than one header on a website; it works just as well for containing the headings within content.
Separate to heading is the hgroup element, which is used to contain a set of multiple heading elements (h1-h6). The most common use for hgroup is with content that has both a heading and subheading. Previous to HTML5, the only way to contain a group of headings would be with generic HTML 4 elements, like div, which isn't ideal as there is no semantic meaning. It is normal for an hgroup element to be included within a heading element.
Copyright notices and details about who made the site are commonly associated with the bottom of a website. The footer element has been created to give these types of content a place to live, because most websites have a footer of some sorts. A footer can also contain things like links to related content, which means they're perfect for use within sections and articles. Like the header element, there is nothing to stop you having more than one footer per page.
As you've probably guessed by now, all the new HTML5 elements have come about because people are trying to do things with HTML 4 that it was never intended to do. Navigation is no different. The nav element has been created with the sole purpose of containing navigational links to sections of a page and other pages of a website. The most common use for the nav element is to contain the main navigation menu of a website. It's often found in a header element alongside a logo or other content typically seen within a header.
Any content that is self-contained and potentially reused in other formats (for example, distribution through RSS) should be placed within an article element. A perfect example of such content would be a blog post. You could remove every other piece of content surrounding a blog post and it should still make sense and retain its meaning. Blog posts are also commonly reused and distributed in formats like RSS. Other examples would be comments, forum posts, and news articles.
Note
Note: There is a lot of confusion about when to use the article element. Bruce Lawson has written an excellent post attempting to clarify the issue.[6] A good rule of thumb is to use article if the content would make sense on its own in a RSS feed reader.
So, as we can see, there are plenty of new elements that help us structure our website in ways that make sense. Fortunately we're a lucky bunch, as we have some more elements to cover. This time the focus is on the new elements that help us group and mark up bodies of content. Elements like figure, figcaption, mark, and time.
A typical use of the figure element is for annotating content with things like images, code, and anything else that helps explain the content in some way. The content within a figure element should be able to be moved outside of the main content without disrupting the flow. In other words, you should be able to remove a figure element and still understand the original content.
<figure>
<img src="example.jpg" alt="An example image">
</figure>Some annotated content requires a short caption to explain what it is, usually because it is shown outside of the context of the original content. To include a caption within a figure element you should use the figcaption element. Simple!
<figure>
<img src="example.jpg" alt="An example image">
<figcaption>This example image will help you understand.</figcaption>
</figure>Content that is highlighted for the purpose of referencing should be included within the mark element. An example would be highlighting a sentence within a quotation that the author of the quote didn't consider important at the time. Another use for the mark element would be highlighting areas of content relevant to a user's current activity. For example, if a user came from a search engine, you could wrap words in your content related to the user's search terms in mark elements.
<p>This is a great example of <mark>HTML5 canvas</mark>.</p>
Note
The mark element is not to be confused with the em or strong elements. The latter denote content that is felt important or worthy of emphasis by the original author. A mark element denotes content deemed relevant in some other context by a different author or as a result of user activity.
When you need a time or date in your content, it's advisable to use the time element. It's important to remember that any time used must be in a 24-hour format, and dates must be in the proleptic Gregorian calendar — the calendar most people in the West use. The time element can also include a couple of attributes: datetime, which indicates the exact date and time specified within the element, and pubdate, which indicates that the date and time given by the element indicates when an article (or the document as a whole) was published. Both attributes take a date in the format YYYY-MM-DD, like 2010-12-25. The datetime attribute is particularly useful when the date inside the time element is represented in a string format that could be misunderstood (such as 24 October, which has no year attached).
<time datetime="2011-09-06">My birthday this year</time>
If you've ever had the luxury of dealing with forms, then you'll understand the pain that is associated with making sure everything is validated and safe. You'll also be aware of the severe lack of control you have when constructing forms. Want a special input that only accepts emails? Tough, have a generic text input instead. Want an input that pops up a calendar so users can choose a date? Sorry pal, you'll need to spend half your life in JavaScript for that. Okay, so perhaps the world of forms isn't quite as grim as that, but there's no denying that the only way you can validate forms and provide intelligent functionality is through JavaScript. However, thanks to what started out as Web Forms 2.0, HTML5 has come to save our collective souls (and our sanity to boot!)
One of my favourite features of HTML5 forms is validation built right into the browser. That means no JavaScript, which means happy Web designers and developers! The problem with the current JavaScript-only system is that you can't guarantee that everyone will have JavaScript enabled. This is why you should always use server-side validation, like PHP, alongside client-side validation, like JavaScript. Having validation baked directly into the browser would not only bring it to everyone that uses the browser, it also means you save a whole bunch of time that you'd normally have spent cooking up validation in JavaScript.
By default, HTML5 form validation is turned on in browsers that support it, although you can turn it off by placing the novalidate attribute in your form element. At the time of writing the only browser to support HTML5 forms fully is Opera (9.5 and later), which displays lovely warning messages if validation fails. Other browsers like Safari and Chrome have a haphazard implementation that is effectively useless — there is no visual feedback for validation errors. Fortunately, browser support is changing at a rapid pace, so it's possible that form validation will work in all browsers by the time you read this.
Anyone who's made a form in the past will know about input types. For those who haven't, an input element is generally used for user input in forms (alongside other elements, like select, textarea, and so on). By setting the type attribute within the input element you're able to make that form input do interesting things; like looking different if someone is entering a password (type = "password"), giving users a selection of checkboxes to tick (type = "checkbox"), or turning it into a submission button (type = "submit"). Input really is the powerhouse behind HTML forms.
The new input types in HTML5 allow you to extend forms beyond things like buttons, checkboxes, and text input. We now have types at our disposal that let us define inputs for email addresses, telephone numbers, URLs. Some of the cooler input types, like datetime, let us select dates using something like a calendar interface. Others, like range, allow us to limit users to choosing a number between a minimum and maximum value. Then you have the color type that lets us choose a colour value using something akin to a colour picker you'd normally associate with a graphics application. A weird choice for inclusion in the HTML5 specification, but most definitely cool!
Alongside input types there are a range of other attributes that can be used in input elements. These range from attributes like placeholder, allowing you to pre-fill an input with a hint for the user, to autocomplete, which lets you toggle whether you want the user's data to be auto-filled based on previous data.
There are numerous other input types, attributes, and other cool features of forms. However, although forms are admittedly very interesting, our time is probably best spent looking at the meatier aspects of HTML5 that are related to this book. Yup, that means it's time for the really cool stuff, media elements!
Before HTML5 came on the scene, external plugins and applications were required to play media in the browser–it was just the way things were done. There was also no built-in support for manipulating graphics–you could only embed images that had already been constructed. One of the core aims of HTML5 is to improve media support, and boy is it doing that. New elements such as audio and video have been introduced that allow media to be played in the browser without the need for any external plugins, like Adobe Flash and Microsoft Silverlight. The canvas element has been brought in so images and graphics can be constructed and manipulated directly within the browser.
The coolest thing about all of these new media elements is that they have open JavaScript APIs that let us take control of media in a really simple way. Want to rewind a video with a custom button? No problem. What about animating some canvas graphics on the fly? Easy peasy. Media in HTML5 is both powerful and exciting, and you don't need to rely on proprietary technology to create it. Never before has this kind of control been implemented at the browser level.
How often do you need an audio player when building a website? For most people the answer to this question is either never or rarely. There's no denying that audio players are a pretty niche requirement on the Web or, at least, they are in their current Flash-based format. On top of that there is a slight hatred of audio on the Web after the influx of websites with auto-playing background music in the 90s. So why then is there a dedicated audio element in HTML5? Because the current methods require you to use a third-party plugin, silly! A cool thing about the audio element is that can be used without rendering it to the page. The beauty of this is that it can be used to complement other features of a website without causing visual mess. For example, you could use an audio element without a user interface for the sound effects of a game — just like what we'll be doing later in this book.
Currently there is no consistent support for the audio element across all the major browsers. There are a grand total of five audio codecs available across these browsers, with none of them all supporting the same codec. The most common of the formats are MP3, and OGG (an open source and free codec). At the moment the best way to implement HTML5 audio cross-browser is to provide an audio source for two or more different codecs. It's not ideal, but it's easy enough to do — you just replace the single src attribute for one or more source elements within the audio element:
<audio controls>
<source src="http://yourwebsite.com/sound.ogg">
<source src="http://yourwebsite.com/sound.mp3">
<!- Insert fallback audio content here, perhaps a Flash player ->
</audio>Hopefully over time a single codec will be supported by all the major browsers. For now we'll just have to put up with this minor hassle.
The great thing about these new media elements is that you can easily provide fallback content, like a Flash player, for browsers that don't support them. Fallback content is provided by placing normal HTML elements within the media element.
For some fine-grained control over the audio element there are a few attributes you can use, other than src, which we've already covered. First up is the controls attribute that, if used, tells the browser to provide a default user interface for controlling audio content (see Figure 1-1).
<audio src="http://yourwebsite.com/sound.ogg" controls>
<!- Insert fallback audio content here, perhaps a Flash player ->
</audio>
If you want audio to loop once, it finishes then there is the loop attribute. But it's worth mentioning that each browser seems to implement looping in a slightly different way.
<audio src="http://yourwebsite.com/sound.ogg" controls loop>
<!- Insert fallback audio content here, perhaps a Flash player ->
</audio>All pretty straightforward so far. Preload tells the browser how you'd like the audio preloaded, if at all.
<audio src="http://yourwebsite.com/sound.ogg" controls preload="auto">
<!- Insert fallback audio content here, perhaps a Flash player ->
</audio>And lastly you have the autoplay attribute, which allows you to have audio content play automatically when the browser loads (please keep the sanity of your users in mind before implementing this).
<audio src="http://yourwebsite.com/sound.ogg" controls autoplay>
<!- Insert fallback audio content here, perhaps a Flash player ->
</audio>Note
Mozilla has put together an Audio Data API that allows for direct manipulation of audio data. With it you can read and write raw audio content through code. Examples of its use are audio synthesizers and visualizations, like you get in iTunes. Currently only Firefox supports this, but it's a very cool sign of what can be done now media is built into the browser.[7]
Audio is cool and all, but combining audio and moving pictures (video) is even cooler. Unlike audio, video content is extremely widespread on the Web, and you'd be hard pushed not to stumble across it somewhere on your travels. However, like audio, the current methods for implementing video content involve external plugins like Flash. And again, like audio, the current methods are bloated and confusing, so it's no surprise that a dedicated video element has been introduced with HTML5 to save the day.
You'd be forgiven for thinking video is harder to implement in HTML5 than audio. Fortunately for us, these two media elements stem from the same guidelines, meaning that they use similar attributes and are implemented in similar ways. A simple video element would look something like this (see Figure 1-2).
<video src="http://yourwebsite.com/video.ogv" controls>
<!-- Insert fallback video content here, perhaps a Flash player -->
</video>Looks mighty similar to the audio example doesn't it? HTML5 consistency win!
There are a variety of video codecs available for you to use, but unfortunately, like audio, none of the codecs are supported by all browsers. To get around this we can use the source element just like we did with the audio element.
<video controls>
<source src="http://yourwebsite.com/video.ogv">
<source src="http://yourwebsite.com/video.mp4">
<!- Insert fallback video content here, perhaps a Flash player ->
</video>Again, like with the audio codecs, I very much hope a single codec will be supported by all browsers in the future. It would certainly make things easier for us.
Because media in HTML5 is awesome, the video and audio elements both share common attributes like src, autoplay, loop, preload, and controls. The video element also brings with it a few special attributes only applicable to video content.
To display an image when the video isn't being played you can use the poster attribute.
<video src="http://yourwebsite.com/video.ogv" controls
poster="http://yourwebsite.com/video_poster.jpg">
<!- Insert fallback video content here, perhaps a Flash player ->
</video>To mute audio on a video by default you can use the audio attribute.
<video src="http://yourwebsite.com/video.ogv" controls audio="muted">
<!- Insert fallback video content here, perhaps a Flash player ->
</video>And to define a specific width and height for the video you can use the width and height attributes.
<video src="http://yourwebsite.com/video.ogv" controls width="1280" height="720">
<!- Insert fallback video content here, perhaps a Flash player ->
</video>Due to codec juggling and support in older browsers, video in HTML5 isn't quite ready for the mainstream just yet, but that doesn't mean you can't start using it. Some big video providers like YouTube and Vimeo are already rolling out experimental HTML5 video support in preparation for the maturing and future uptake of HTML5. In any case, you can always use a traditional Flash video as fallback for a HTML5 video if you really want to use it on your website.
Note
A major reason why HTML5 media is so important is that it provides a completely open way of implementing audio and video. Before this you were limited to closed systems like Flash, which, although functionally sound, make it difficult to control media outside of the plugin. HTML5 doesn't place these restrictions on you and allows you to control and manipulate media in any way you like, anywhere you want. See The Definitive Guide to HTML5 Video by Silvia Pfeiffer (Apress) for a detailed examination of video in HTML5.
Easily my favorite feature of HTML, the canvas element is the reason behind writing this book and, in some part I hope, the reason why you're reading it. This element is very different from the others as its main purpose is to manipulate 2d graphics or create them from scratch, rather than simply embedding existing media like with the audio and video elements. I suppose you could imagine it like Microsoft Paint built into the browser. But don't despair, as I can assure you it's much, much better than and, in reality, nothing like Microsoft Paint! My point is to look at it as a 2d graphics environment instead of a simple container for embedding media.
Note
Did you know: Apple originally invented the canvas element for creating Dashboard widgets, but it quickly caught on with other browser manufacturers and eventually made its way directly into the HTML5 specification.
I'd be doing canvas an injustice if I didn't give you a better insight into its possibilities. Yes, it may only be a 2d platform (for now), but that doesn't mean it can't do some pretty amazing stuff. For example, by manipulating the canvas element with the JavaScript API you can create dynamic graphics and animations that react to user interaction (like games — some genii at Google even ported the first-person 3D shooting game Quake II into canvas). You can use it to create data visualizations and graphs based on data in a HTML table, which updates on the fly. You can use it to construct a UI for a Web application, although I'd probably advise using traditional HTML and CSS for that. What I';m getting at here is that the canvas element is simple and benign but, together with the JavaScript API and a bit of imagination, canvas as a whole is a massively potent tool for creating dynamic graphics and interactive experiences. In a nutshell, canvas is really exciting!
Note
You may have noticed that I refer to both the canvas element and canvas. There is a subtle distinction. I will refer to the canvas element when directly talking about the HTML5 element and its features, not including the JavaScript API. I will refer to canvas (without the emphasis) when talking about the whole family of canvas-related features as a whole (the canvas element, the JavaScript API, the sense of awe you receive while using it, and so on).
So that's all you need to know about the canvas element. Now you can go off and create these amazing graphics and games. But, isn't there more? I hear you ask. Well, you've got me. I lied. There is so much more to say about canvas and what can be done with it. We've not even scratched the surface yet! Future chapters are dedicated to learning more about this powerful element and how to control it. You'll be a master of canvas in no time.
It's all well and good learning about the new elements in HTML5, but until you see them in context it's hard to imagine how they're used. So that is exactly what we're going to do now. I';m going to show you an example HTML5 Web page and then we'll dissect it line by line and learn how the new elements are used in a real environment. The example page we're going to look at is for an imaginary blog homepage, which will include a header, some blog posts, a sidebar, and a footer. We won't be styling the page so I've left out things like CSS and presentational attributes. We're concentrating purely on how a HTML5 website is structured.
Here is the full code for our HTML5 blog homepage. Don't worry if it's all a bit much right now.
<!DOCTYPE html>
<html>
<head>
<title>A basic HTML5 blog homepage</title>
<meta charset="utf-8">
<!-- CSS and JavaScript to go here -->
</head>
<body>
<header>
<!-- Website name and navigation -->
<h1>My amazing blog</h1><nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/archive/">Archive</a></li>
<li><a href="/about/">About</a></li>
<li><a href="/contact/">Contact</a></li>
</ul>
</nav>
</header>
<section>
<!-- Blog articles - repeat as many times as required -->
<article>
<header>
<hgroup>
<h1><a href="/blog/first-post-
link/">Main
heading of the first blog post</a></h1>
<h2>Sub-heading of the first blog post</h2>
</hgroup>
<p>Posted on the <time pubdate datetime=
"2010-10-30T13:08">30 October 2010 at 1:08 PM</time></p>
</header>
<p>Summary of the first blog post.</p>
</article>
<article>
<header>
<hgroup>
<h1><a href="/blog/second-post-
link/">Main
heading of the second blog post</a></h1>
<h2>Sub-heading of the second blog
post</h2>
</hgroup>
<p>Posted on the <time pubdate datetime=
"2010-10-26T09:36">26 October 2010 at 9:36 AM</time></p>
</header>
<p>Summary of the second blog post.</p>
</article>
<article>
<header>
<hgroup><h1><a href="/blog/third-post- link/">Mainheading of the third blog post</a></h1> <h2>Sub-heading of the third blog post</h2> </hgroup> <p>Posted on the <time pubdate datetime="2010-10-21T17:13">21 October 2010 at 5:13 PM</time></p> </header> <p>Summary of the third blog post.</p> </article> <!-- Blog sidebar --> <aside> <h2>Subscribe to the RSS feed</h2> <p>Make sure you don't miss a blog post by<a href="/rss">subscribing to the RSS feed</a>.</p> </aside> </section> <footer> <!-- Copyright and other stuff --> <p>My amazing blog © 2010</p> </footer> </body> </html>
Still with me? Let's start from the top.
<!DOCTYPE html>
This is the new spangly HTML5 doctype declaration and, although it may look like it, it's not an element. The purpose of the doctype is to tell the browser which version of HTML (or XHTML) we're using — how to render it and what kind of validation to use. In HTML 4.01 the doctype looked much different and involved you knowing if you were using a strict, transitional, or frameset document type. Like so:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
A bit much, don't you think? Fortunately the HTML5 doctype is much simpler and doesn't require anything further than the text, "html". What's even better about the new doctype is that it doesn't break browsers that don't support HTML5, they just revert to something called standards mode — rendering the page as close to W3C standards as possible. So there really is no reason why you can't start using the HTML5 doctype today.
<html>
The html element is the root of our page; everything else is placed within it. There should only ever be one of these elements per page.
<head>
All of the meta elements for our page are contained within the head element. There should only ever be one of these elements per page.
<title>A basic HTML5 blog homepage</title>
We give our page a name with the title element, it will be displayed in the title bar of your browser window. There should only ever be one of these elements per page.
<meta charset="utf-8">
The meta element is used to represent other metadata about our page. The charset attribute declares the method of character encoding that we want to use. Unless you have a legitimate reason for doing otherwise, stick with UTF-8 character encoding.
<!-- CSS and JavaScript to go here -->
This is a HTML comment. You should replace it with links to your CSS and JavaScript files.
</head>
We're finished setting metadata for our page, so we can close the head element.
<body>
The main content of our page goes within this body element. There should only ever be one of these elements per page.
<header>
Everything related to the header of our page, including a website name and some navigation, is contained within this HTML5 header element.
<h1>My amazing blog</h1>
This h1 element displays the name of the website on our page.
<nav>
The website navigation is stored in this HTML5 nav element.
<ul>
We're using an unordered list to structure the navigation menu.
<li><a href="/">Home</a></li> <li><a href="/archive/">Archive</a></li>
<li><a href="/about/">About</a></li> <li><a href="/contact/">Contact</a></li>
Each part of the navigation is stored as a link (an href element) within a list item (an li element). Without styling, this will list the navigation items one-by-one, one under the other.
</ul>
We're finished with the navigation items, so we can close the unordered list.
</nav>
The website navigation is finished, so we can close that as well.
</header>
And the same with the header.
<section>
We're using a HTML5 section element to contain our blog posts. This isn't entirely necessary; if we know there is only blog content on the page, we can remove the section element entirely.
<article>
To distinguish each blog post, we contain them within a HTML5 article element. Remember, we use the article element for content that would make sense on its own in an RSS reader.
<header>
Here we open up the header of the blog post.
<hgroup>
As we're using multiple headings in our blog posts, we're containing them within a HTML5 hgroup element.
<h1><a href="/blog/first-post-link/">Main heading of the first blog post</a></h1> <h2>Sub-heading of the first blog post</h2>
Here we declare the main heading for the blog post, with link, as well as the subheading.
</hgroup>
We're done with the headings, so we can close the hgroup element.
<p>Posted on the <time pubdate datetime="2010-10-30T13:08">30 October 2010 at 1:08 PM</time></p>
Still in the header, we output the data and time the blog post was published using a HTML5 time element. Notice how we set the pubdate attribute, as this is the date a piece of content was published. Also, note the use of the datetime attribute to give a correctly formatted version of the date and time.
</header>
The blog post header is complete so we can close the header element.
<p>Summary of the first blog post.</p>
A simple paragraph giving a summary of the blog post.
</article>
We're done with the first blog post so we can close the article element. The process for the other blog posts is exactly the same, so I've removed them for brevity.
<aside>
To create related content we use a HTML5 aside element. We use this instead of something else, like a section element, because the sidebar is directly related to the content around it — the blog posts.
<h2>Subscribe to the RSS feed</h2>
The heading of the sidebar. Notice how we're using an h2 element here, as the heading is less important than the others on this page.
<p>Make sure you don't miss a blog post by <a href="/rss">subscribing to the RSS feed</a>.</p>
A simple paragraph with a link to subscribe to the imaginary RSS feed.
</aside>
We're done with the sidebar, so we can close the aside element.
</section>
Everything related to the blog posts is finished, so we can close the section element.
<footer>
We contain all of our footer content, like the copyright statement, within a HTML5 footer element.
<p>My amazing blog © 2010</p>
A simple paragraph with the copyright statement for our page.
</footer>
That's all for the footer, so we can close the footer element.
</body>
We're done with all the content for our page, so we can close the body element.
</html>
We've reached the end of our page, so the last thing left to do is to close the html element.
That wasn't too bad, was it? As I hope you can see, using HTML5 isn't all that hard. The main issues are understanding what all the new elements do, when to use them and, most important, why you'd use one element instead of another. The best way to get to grips with HTML5 is by constructing a proper website using the new elements. Try it on your own website. You don't even need to put it online; just converting it into HTML5 is good enough to get something out of it.
As with any new technology, a lack of understanding often leads to misconceptions about what it is and what it does. HTML5 is no different, and it suffers from a massive lack of understanding and confusion regarding its features and those of other technologies. So prevalent is the issue that it's no wonder people find it hard to work out what is HTML5 and what isn't. Even I find it hard sometimes. So I've made it my personal duty to clear up the most common misconceptions about HTML5. My hope is that, armed with this information, you can go forth and not only sound intelligent, but help the Web community as a whole.
CSS has been around for HTML since 1996 — it's an old technology. The latest version, CSS3, has been in development since 2005 and is still nowhere near full recommendation by the W3C. In fact, it's not even being developed and recommended as one big specification. It has been split into individual modules that are being implemented by browsers as they are worked on. Because of this it's hard to say when CSS3 will be classed 100 percent complete, although, like HTML5, parts of it are already usable in most browsers.
The important thing to note with CSS is that it is separate to HTML in both development and use. CSS3 is not part of the HTML5 specification (it never was, and never will be). They are two completely different technologies — one for structure and layout, the other for presentation — that, because of their close proximity in use, have been bundled together for some reason. The bottom line? Don't refer to CSS3 as HTML5.
One of the massive drawbacks with Web design has been that it's incredibly hard to use custom fonts. Up until recently the only way you could do that was by constructing static images depicting the words you want to use, or by using convoluted systems like sIFR or cufon. Web Fonts solves this issue by introducing the @font-face rule to CSS, which allows you to use custom fonts with just a couple lines of code. Much easier!
Imagine if you could automatically get information on the Web related to your current location, wherever you are. The Geolocation API is doing just this by providing Web developers with a way of knowing where a user is by using some simple JavaScript. A user has to allow this location information to be shared, but the implications of doing so are profound — like related advertisements, useful search results, and relevant website content. All of this is provided without you having to type in or select your current location.
Scalable vector graphics (SVG) is a language that allows you to create 2d vector graphics using XML. It is very much similar to canvas in its functionality and purpose, but differs substantially in other areas (which I'll discuss in Chapter 10).
Cookies. Everyone's favorite snack and, coincidently, the method of choice for storing small pieces of information on a user's computer. Until now it has been the only viable method of storing data on the client-side (the user's computer), but it has a few flaws that can potentially cause a lot of pain. Web Storage, a set of JavaScript APIs, has been created to offer a powerful selection of new storage options that solve the inherent downsides of using cookies. They don't sound as cool, but they open the door to things like viewing your browser-based email inbox offline. Cool!
Web Workers are essentially tireless JavaScript slaves ready to do your bidding. Their sole purpose is to perform heavy calculations and other intensive tasks in the background, without causing the Web page to slow and disrupting the user's experience. There aren't a huge number of use-cases for Web Workers, but it's good to know that they're there in case you do need them.
Normal communication over the Web is done via HTTP, a method that only allows communication in one direction at a time, and requires a Web page to be requested each and every time you want new data. To get around this Web developers have been using a whole host of options to circumvent the requirement for having to request a new page. Technologies like Ajax and Comet were invented for this very purpose. However they still weren't truly bi-directional methods of communication — information still only travelled in a single direction at any one time.
WebSockets are different; they use TCP which allows for true bi-directional communications between a client (your computer) and a server. This means you never have to make a request for new data from the server, as information is literally streamed to your computer in real-time as and when new data arrives. It's a complicated concept, but a very powerful one once you get to grips with it.
No — it's a JavaScript API that is designed to be implemented by browsers that want to support it. You can find out more about the WebSocket API at http://dev.w3.org/html5/websockets/.
Although all of these technologies aren't part of the HTML5 umbrella, they all solve a distinct purpose and they should be embraced and used together with HTML5 whenever possible. The point of this section is to highlight the reason why these technologies aren't part of HTML5, not to put you off using them altogether. For example, by combining WebSockets with HTML5 canvas you can create amazing real-time multiplayer games. Now that's a cool combination of two different technologies!
This chapter has taken you on a journey through the history of HTML. You've travelled a great distance, from the recommendation of HTML 4.01 in 1999, right up to the development of HTML5, which is still ongoing to this day. I explained the reasons why HTML5 is needed, and how it is going to meet those needs. We've taken a look at all of the major new elements and and features of HTML5, learning their purpose and the ways they can be used. You've learned how to put all of this together to construct a Web page in HTML5. Lastly, I've made clear the confusion surrounding HTML5 and other new Web technologies.
It's been a very wordy chapter (well done for sticking with it) and I promise you that now we have the basics out of the way, future chapters will be much more hands-on. After all, you've come here to learn stuff, not listen to me drone on about the history of HTML5!
Next up, the fundamentals of JavaScript.
For those of you who did enjoy learning the history of HTML5, or those of you who'd like to know more about the elements and features we aren't discussing further, here are a few resources for you to consume at your leisure.
Introducing HTML5, by Bruce Lawson and Remy Sharp [
http://introducinghtml5.com/]HTML5 Doctor [
http://html5doctor.com/]Dive Into HTML5, by Mark Pilgrim [
http://diveintohtml5.org/]WHATWG HTML5 Specification [
www.whatwg.org/specs/web-apps/current-work/multipage/]
[1] http://www.w3.org/html/wg/wiki/History
[2] http://www.w3.org/TR/html4/
[3] http://www.whatwg.org/specs/web-apps/current-work/multipage/
[4] TomiAhonen: Mobile Industry Numbers 2010
[5] http://www.whatwg.org/specs/web-apps/current-work/multipage/
[6] http://www.brucelawson.co.uk/2010/html5-articles-and-sections-whats-the-difference/
[7] https://wiki.mozilla.org/Audio_Data_API