An Introduction to HTML5
It seems like everyone is talking about HTML5 now, but the discussion is spread out and seldom gives the background, explanation what HTML5 really is and if/when it’s usable.
Therefore, my ambition here is to:
- Give you a little history
- Go into what HTML5 is and what it covers
- Show code examples
- Target the question whether you can start using it or not
The HTML5 work stems from the WHATWG (Web Hypertext Application Technology Working Group), and their focus is the development of HTML and APIs for web applications. The reason it came to life back in 2004, founded by people from Apple, Mozilla and Opera, was a worry about the direction W3C were taking with XHTML, and no focus on HTML or the real-life needs for web developers.
It got really interesting in July of 2009, when W3C announced that XHTML2 would be cancelled in favor of HTML. This means that the only future development of HTML and XHTML is in the form of HTML5 – HTML5 is the future, whatever you think about it.
I should also mention right away that HTML5 is spelled just that, with no space between the the L and 5 – read more in Spelling HTML5.
What is HTML5
So what is HTML5, really? Basically, it’s about extending HTML/XHTML with new more semantically rich elements, deprecating attributes, introducing new attributes and altering how some element and attributes are allowed to be used. Hand in hand with that is the possibility to use attributes for WAI-ARIA to make a web page more accessible, such as with landmark roles.
It also introduces a number of APIs for making it easier to create web applications:
- 2D drawing API with the canvas element.
- API for playing of video and audio with the video and audio elements.
- API that enables offline Web applications.
- API that allows a Web application to register itself for certain protocols or media types.
- Editing API in combination with a new global contenteditable attribute.
- Drag & drop API in combination with a draggable attribute.
- API that exposes the history and allows pages to add to it to prevent breaking the back button.
- Cross-document messaging with postMessage.
Other things that initially was in the specification, but broken out into separate specifications are:
- API for Geolocation
- Web Storage.
- Web Workers.
I think the best document to read to grasp the changes are HTML5 differences from HTML4, which will cover:
- Open Issues
- Backwards Compatible
- Development Model
- Impact on Web Architecture
- Character Encoding
- The DOCTYPE
- MathML and SVG
- New Elements
- New Attributes
- Changed Elements
- Changed attributes
- Absent Elements
- Absent Attributes
- Extensions to HTMLDocument
- Extensions to HTMLElement
Backwards compatibility & progressive enhancement
I think one of the main reasons behind the adoption of HTML5 is that it sets out to be backwards compatible and work with the web browsers there already are in the market, and have been for some time, too. This is done through new elements which, generally, have no particular look or behavior attached to them, but rather offering more semantic richness and then up to you style them via CSS according to your liking.
The other parts are new elements that have been implemented in some web browsers, and not in others, where the progressive enhancement approach that has been preached for a long time comes into play. Meaning, use the new elements which will give a richer experience in some web browsers, whereas it will fall back to default content in others.
Example in question: a cascade of new input element types:
So far, WebKit and Opera have been the most busy rendering engine to implement some of these, especially in relation with Opera’s work with WebForms 2.0 support, but in other web browsers it will fall back to a regular input type="text". That means, for instance, that input type="search" will will give subtle, but better user experience, in Safari and Google Chrome, but will be a fully functional for all others.
The beauty of progressive enhancement.
HTML5 code introduction
Let’s get down to some code introduction and what you need to be aware of when you start coding HTML5.
The doctype for HTML5 looks like this:view sourceprint?1.<!DOCTYPE html>
No versioning, no redundant information. All progressive enhancement on a feature-level, as opposed to complete releases that need to be implemented.
And, to be a bit more pragmatic than before, HTML5 will allow both quick-closing of empty tags (such as input, link etc), but you can use those elements just as well without quick-closing them. Quotes for attributes are also optional, and you know what? You can even use upper-case letters for your element names of you will!
All of these examples are valid HTML5:
<p id=john>John's P</p>
<input type="text" />
This might be scary to some people, and I agree with the concerns the HTML5 Super Friends presented, where they want a way to, in a more stricter way, be able to validate the consistency of the code. However, with all different people’s coding styles and our legacy, allowing this freedom was probably the only pragmatic option to get people along, instead of fighting battles that will never be won.
And, a great thing is that you can now wrap entire blocks with an a element to make that entire block a link to somewhere!HTML or XHTML
I should also mention that there are two options to serve HTML5 content: as HTML or XHTML. The somewhat confusingly named XHTML5 differs a bit from HTML5, though:
- No doctype is needed, just an XML prolog.
- It must have a namespace: <html xmlns="http://www.w3.org/1999/xhtml">
- It must be served with either of these MIME types: application/xhtml+xml or application/xml.
- The noscript element can not be used.
Lot’s of the research behind HTML5 has been how people name their elements, with IDs and classes, and part of the result are new elements named/inspired by those. There are a lot of new elements in HTML5, where these are probably the most interesting as you can use them right away in any web browser.
- Mark up parts of the content that is independent, for instance blog post, article etc.
- Used to mark up relevant additional information, like a sidebar.
- Used for natively including audio in a web page.
- The counter-part to header; could be used for any footer section per context.
- Used for headers in its context. Note: not just for the header of a page, but also for each header part in section, article and similar.
- Used for grouping several headers, for instance, a main heading and a sub-heading.
- Used for marking up main navigation.
- Mark up a generic document section. Easily confused with article, and on top of that you nest either of them, in any order, with the other.
- Used to mark up a time or date.
- Used for natively including video in a web page – lots of interesting work is coming along here in terms of web browser support.
Let’s get down to some actual code and see what an HTML5-coded web page could look like. I have put together a simple HTML5 example with new elements and WAI-ARIA landmark roles as part of my HTML5 demos page (quite sparse now, I know, but I will incrementally add examples to it).
This is the complete source code of that web page:
<title>HTML5 example with new elements and WAI-ARIA landmark roles</title>
<link rel="stylesheet" href="css/base.css" type="text/css" media="screen">
<!--[if lte IE 8]>
<h1>HTML5 example with new elements and WAI-ARIA landmark roles</h1>
<p>This page has valid simple HTML5 markup complemented with WAI-ARIA landmark roles for accessibility</p>
<li><a href="http://robertnyman.com/html5">HTML5 demos and samples' start page</a></li>
<li><a href="http://robertnyman.com/">Robert's talk</a></li>
<div id="demo-main" role="main">
<h3>Subtitle to the above title</h3>
<p>Some content, created <time datetime="2009-10-14">October 14th 2009</time></p>
<p>Some more content - i guess you get the drift by now</p>
<h2>The HTML code for this page</h2>
<aside id="demo-aside-content" role="complementary">
This is just a demo page to see HTML5 markup and WAI-ARIA landmark roles in action in a simple context
<footer id="page-footer" role="contentinfo">
Created by <a href="http://robertnyman.com/">Robert Nyman</a>
As you can see, it looks more or less than every other HTML web page you have ever seen, but with just a few new HTML elements being used and the role attribute with landmark roles for WAI-ARIA to make it more accessible.
If you want a more real-world example, just view the source code of robertnyman.com: I have now rewritten it as HTML5!
Can I use it today?
I would say yes!
There was some wild speculation about the date 2022, because one of the main men behind the work with HTML5 and the specification was asked in in an interview about HTML5 and its timeline, and the date 2022 was mentioned. Then everyone assumed that HTML5 wouldn’t be ready until 2022, which is not was addressed, but rather when web browsers would have two releases with completely full support for HTML5 (compare that to CSS 2.1 support etc and the time it has taken, and you will probably get a more sane reaction). Read more about in 2022, or when will HTML 5 be ready? if you want to know more.
But let’s go through the pros and cons, and I will explain why HTML5 is ready to be used.
- Major players using it
- To begin with, a lot of major players have already started implementing it. Google.com already have the HTML5 doctype (although they should really improve the markup accordingly), the new hyped Google Wave is revolving a lot around HTML5 and related APIs (which ironically uses a HTML4 Strict doctype…) and there is also a YouTube HTML5 demo page.
- Strict rendering
- The HTML5 doctype will trigger the strictest rendering in all web browsers. No Almost Standards Mode, no quirks; strict all the way, which is the way we want, and the way it should be.
- Progressive enhancement
- You can start today just by changing the doctype. Then gradually move onto exchanging some structure elements, sprinkle it with some WAI-ARIA etc and before you know it, you have a fantastic HTML5 page!
- Validation available
- Now even the W3C Validator supports HTML5. Just use the Firefox Web Developer Extension to validate your HTML against it. The HTML Validator extension unfortunately doesn’t support it yet, but I know there are at least plans to include this – if you have any ides or input, please help him out.
- It probably doesn’t matter much right now, but in the future, I think that web sites that are marked up in a much more rich fashion with new HTML5 elements to give them the multitude they need, will benefit a lot from this.
Ah, right, drawbacks. There are always some, isn’t there?Internet Explorer
It probably doesn’t come as a shock to you, but Internet Explorer, all current versions (yes, including IE8 as well) has a little issue: it won’t apply any CSS to an unknown element (e.g. nav, section etc).
The gist of it is that you need to call document.createElement with the name of each new HTML5 element you use in the page. You don’t need to use it to append or place those element, just call it to make IE aware of them. Remy Sharp has written a little HTML5 enabling script for Internet Explorer, version 6 to 8 which works in all possible cases.
People eager for HTML5 has argued that we will need script dependency for IE to render styling for those elements, otherwise it will render unstyled, but with the content still fully accessible. While I agree in theory, I think it is, at times, an unnecessary requirement for using HTML5.
Another option is the content negotiation approach, where we on the server exchange the new elements for old ones just for Internet Explorer. It’s simple: just have a regular expression to replace all block elements (header, footer, section etc) with div elements, and the inline ones (time, mark etc) with span elements.
Together with that, always style you elements through their id attribute or class value, and you are good to go! All modern web browsers + screen readers + search engines will get rich HTML5 markup; IE will get plain old HTML.
There are still some discussions about some elements in HTML5 and how they should be specified, what existing options/combinations there are that will work in existing user agents (which is a must; it can’t break things). Overall, though, I’d say use the new parts everyone agrees about and that will work, and hold on with the bells and whistles until it’s ready.
The last call for the HTML5 working draft is in October this year. The future is already here.
Where we are today on the web
I for one is really happy that this is finally becoming true and usable. Sure, as always there are a number of issues and things to discuss, but overall we really need this as web developers. We need new elements, APIs and options to create dazzling web sites, and we have been waiting so long for something new at all.
I also think this is vital for the climate of the web, to have open standards to code after, and to compete with the ever-growing closed-in and proprietary technologies that try to claim the web as their own.
Have me do a presentation
If you found all this to be immensely interesting, and would like to discuss it in real life or hear more, please contact me if you want me to talk at a conference, your company or similar!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)