Remy Sharp talks about what’s coming with HTML 5, what happened to XHTML 2, and how XHTML is not dead, and why HTML 5 is here today, and not 2022.
This July the XHTML 2 working group announced that it would be dropping the spec and closing the book on XHTML 2.
That’s XHTML with a 2 at the end. Not XHTML. XHTML is alive and well, it’s just not getting the overhaul that was intended with XHTML 2.
If you’re a developer or designer that writes markup, then you’re possibly already using XHTML 1.0 or 1.1, strict, transitional or otherwise. I’d also be willing to bet that if you’re using it, you’re using it to make use of stricter validation rules: lowercase tags, double quoted attributes, self closing tags (like <br />) and so on - right?
Equally, if you’re that type of designer or developer, you’re probably also not serving it as true XHTML. Quite simply because Internet Explorer won’t accept it. IE doesn’t accept the application/xhtml+xml mime type at all, which is a requirement for XHTML.
This is old news though. The new news is XHTML 2 is dead. The idealist recommendation for the web didn’t make it. Possibly because of the lack of backward compatibility, possibly for lots of reasons, and the web is hot discussion on the loss of the spec and why, and who, and whoh.
However there is hope! If you’re the type of designer or developer who likes the strict rules of markup design, that runs everything carefully through a validator then you’ll be over the moon to know two things:
XHTML 5 is quite simply HTML 5 plus XML, i.e. all the normal rules of XHTML, like no document.write allowed.
For it to be XHTML 5, however, do must serve it as application/xml or application/xhtml+xml (which isn’t currently supported in IE), so HTML 5 with lovely XHTML style markup is the way I’ll be going.
Before we dive in to what’s in HTML 5 and what we have to do get it going, I want to address the future: 2022.
Aside from being the year Queen Elizabeth II will celebrate her Platinum Jubilee (assuming she’s still kicking around), it’s the date that’s been inappropriate linked with HTML 5 in the minds of a lot of our community.
I understand why someone might think that, but it’s wrong. 2022 was misinterpreted as the year HTML 5 would be ready. That’s wrong. HTML 5 is ready today.
In an interview by Tech Republic, for a techie audience, Ian Hickson, the editor of the HTML 5 working draft, was asked to give a timeline of the HTML 5 recommendation.
One date should have come out of that interview, but another, much further away did instead: 2022 - the date of the final proposed recommendation, which actually translates to:
require at least two browsers to completely pass [HTML 5 test suites]
Let’s put this in context of another spec that has taken a very long time: CSS 2.1.
CSS 2.1 is CSS that I’m certain you’re familiar with. I’m certain you use it day to day without any thought as to whether it’s a completed spec.
It’s been in development for over 10 years, and it’s only just become a recommendation (23rd April 2009).
That said, it doesn’t have two browsers completely supporting it. Only Internet Explorer 8 supports the full CSS 2.1 spec.
Did that stop you from using CSS 2.1? I suspect not. Will that stop us from using HTML 5? It certainly shouldn’t. HTML 5 is available and ready to use today.
October 2009.
This October is the last call for the HTML 5 working draft.
That means, that issues with the spec, enhancements, bugs, anything, it all needs to be in and submitted and written in to the spec for October this year.
The WHATWG is completely open for anyone to contribute their ideas and suggestions, compared to the W3C working groups are closed and invite only for experts.
You can sign up to the mailing lists, look through the backlog of mailing list. You can communicate directly using IRC and there’s even a complete log of all the IRC history. All available from http://whatwg.org.
The way to get the browser to switch to HTML 5 is super über easy, you change your DOCTYPE from whatever it is now to this:
<!DOCTYPE html>That’s it. It doesn’t require anything more than that.
Google are doing it already. Check out their one line homepage in all it’s glory starts with:
<!DOCTYPE html><head><title>HTML 5 - Google Search</title><script>...…and then goes on for one great big line. Ironically though, the Google search page and listings doesn’t validate because of their use of invalid tags, font for instance, and a number of other errors. However, they are running with HTML 5, regardless of their markup errors!
Although that’s all you need for HTML 5 to be triggered, there’s a lot more to HTML 5 for you to play with.
If you want something a little fuller, here’s a typical boilerplate for HTML 5:
<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />
<title>My first HTML 5 page</title>
<style>
body { font-family: helvetica; }
</style>
</head>
<body>
<p>Hello World</p>
</body>
</html>A note about the style and script elements in HTML 5:
These both no longer need the type attribute as they default to text/css and text/javascript respectively, which just helps to remove a little more cruft from our markup.
Way back when we were laying pages out using the table element we probably weren’t aware of semantics and standards. Nowadays we’re using div’s left right and centre. The situation isn’t terrible, because most of us are using semantic classes and ID naming conventions to describe what the function of the div is. Wouldn’t it just be better if we had a header and footer element instead?
HTML 5 gives us exactly that.
One of the biggest assets of HTML 5 is the new semantic markup. There’s an arsenal of new elements that has been added to HTML 5, and because of the pave the cowpaths approach, these can be used by the browsers by today*.
Here’s a non-exclusive list of the new HTML 5 elements that are available.
article - represents a section of the page that consists of content that’s an independent part of the document, page or site. This can be a forum post, blog post, user comment or any other independent item of content.aside - is used to represent a section of content that is related to the content around the aside element, for example a pull quote.footer - the footer to a section. This is not restricted to one use at the bottom of the page. You can also use the footer to markup the footer of a blog post in addition to the footer of the entire document.header - represents a group of navigational aids, and is used to construct the document outline. You are also not restricted to using header only once, you could use this to markup author’s name and time of a comment placed on a blog post for example.nav - used to wrap major navigation blocks, such as table of contents, pagination links and breadcrumbs. Note the menu is for lists of commands, like a toolbar, and should not be confused with the nav element.section - a generic document or application section. However, this isn’t a replacement for the div element. A section is only appropriate “if the element’s contents would be listed explicitly in the document’s outline”.details - used to include additional information that the user can obtain on demand. An open attribute on the element determines whether it’s contents can be seen, and it can be toggled using JavaScript.figure - used to annotate illustrations, photos, listings, etc, that if moved away from the primary content would not affect the flow of the document.mark - highlights a run of text, for example to mark the terms the user was searching for.time - intended to encode modern dates and times in a machine readable way. The datetime attribute on this element gives the machine readable time, whereas the contents is human readable.The following elements include DOM interface methods that allow them to function correctly. Therefore, if the browser hasn’t implemented these elements specifically, they won’t work. However, they all support fallbacks using nested elements within the tag to degrade down to a working solution.
audio, video - both are types of media elements, allows you to embed audio and video directly in to the browser without any need for plugins. However, where support is lacking in the browser, best practise suggests that you should fail back to Flash plugins. You can either let the browser render the chrome for the element, or you can take control via JavaScript to create a bespoke interface.source - this element is a child element to the audio and video. It allows you to specify multiple alternative sources for the media element. For example, Firefox doesn’t support the WAV audio format, so you can specify an alternative source in Ogg Theora format.canvas - A 2D drawing element which can be accessed using JavaScript to render graphics on the fly, for example for games, graphs or animations.datagrid - used to represent interactive data for a tree, a list or tabular data. This element includes a large collection of DOM methods to interact and manipulate that data.Where the new elements aren’t relying on a new DOM interface to be available to the browser, the element is available to you right now.
The media elements audio and video have a new DOM interface, so only those browser that have specifically implemented these media elements will be able to offer native audio or video.
However, this shouldn’t hold you back from using these elements. If you use the video element and it’s not supported in the browser, it’s contents will be rendered.
For example, for my video element, I’ll first provide an Ogg Theroa encoded video, then QuickTime, then finally degrade down to Flash if the video element isn’t supported:
<video height="640" width="360">
<source src="example.ogg" type="video/ogg" />
<source src="example.mov" type="video/quicktime" />
<!-- otherwise let the user see flash -->
<object height="640" width="360" ...>
<param value="..."></param>
</object>
</video>However there are a couple of browsers that do have trouble seeing the new elements natively.
In particular, all versions of Internet Explorer can’t see the elements by default, and as such they can’t be styled without the help of a bit of JavaScript.
Firefox 2 and Camino 1 have a bug in the Gecko rendering engine that cause the DOM to render incorrectly. However Firefox 2 had it’s A-grade support dropped earlier this year, and these two browsers have a very solid upgrade path (hence why they have been dropped from A-grade support in the first place). There are a few ways to fix Firefox 2 and Camino 1 and you can read about them here: http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/
So IE is problematic. What’s new, right? The fix is actually incredibly simple, and if you’re using any of the new DOM APIs or new HTML 5 JavaScript APIs (which I’ll come to), the requirement for JavaScript is justified.
Sjoerd Visscher first posted about this solution where by IE is able to style any element so long as you run the following code:
document.createElement('myelement');Now myelement can be styled using CSS in IE.
Now we have an HTML 5 shiv to enable all the HTML 5 elements for IE. So long as this script is included in the head element, then you’re able to style the document correctly:
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->If JavaScript isn’t enabled, the document will be displayed as if CSS hadn’t been applied to the document, which given that we’re used to writing semantic standards based markup - means all the content is accessible and readable regardless.
As with any browser, all the default styles for all elements are part of the browser. Since the browsers don’t really know about these new elements by default, we need to give the block elements their initial default styles.
This is fixed by including the following CSS in your style sheet:
header, nav, section, article,
dialog, figure, aside, footer {
display: block;
}HTML 5 is much, much more than just markup changes. You’ve already seen the audio and video elements can be interactive. They expose a totally use DOM interface that JavaScript can interact with.
Included in the HTML 5 spec is a host of JavaScript APIs - along with a bunch of JavaScript APIs that used to be in the spec and have since been moved out to their own specs.
New HTML 5 JavaScript APIs include:
The specs are changing all the time leading up to the last call (in October 2009). Some of the other interesting JavaScript APIs include:
document.querySelectorAll uses CSS syntax to find elements in the DOM.HTML 5 is here to stay, like it or not. The semantic elements are ready to be used today, and a decent amount of the JavaScript APIs are available in the latest browsers to be played with an integrated in to your cutting edge applications. So go play!