/Culture/ HTML5 today!

Remy Sharp talks about what’s coming with HTML5, what happened to XHTML2, how XHTML is not dead and why HTML5 is here today, and not 2022 (phew!)

Is XHTML dead? In July 2009, the XHTML2 working group announced it would be dropping the spec and closing the book on XHTML2. That’s XHTML with a 2. Not XHTML. XHTML is alive and well – it’s just not getting the overhaul that was intended with XHTML2.

If you’re a developer or designer who 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 doesn’t accept the application/ xhtml+xml mime type at all – which is a requirement for XHTML. T his is old news, though. The new news is that XHTML2 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 – the web was hot with discussion on the loss of the spec; the why, who and “whoh!”.

However, there is hope. If you’re the type of person 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:

1. HTML5 supports all the lowercase, self-closing tags, double quoted attributes – the works. And if you don’t like these things, it supports that too!

2. If you absolutely have to have XHTML in your bag of tricks, XHTML5 will satisfy your thirst.

XHTML5 is quite simply HTML5 + XML, ie all the normal rules of XHTML, like no document.write allowed. For it to be XHTML5, though, you must serve it as application/xml or application/ xhtml+xml (which isn’t currently supported in IE). So HTML5 with lovely XHTML-style markup is the way I’ll be going.

Before we dive into what’s in HTML5 and what we have to do to get it going, though, I want to address the future: 2022. Aside from it being the year Queen Elizabeth II will celebrate her Platinum Jubilee (assuming she’s still kicking around), it’s the date that’s been inappropriately linked with HTML5 in the minds of many in our community.

It’s wrong. In fact, HTML5 is ready to use today. So why the confusion?

In an interview by Tech Republic, Ian Hickson, the editor of the HTML5 working draft, was asked to give a timeline of the HTML5 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 HTML5 test suites.

Let’s put this in context of another spec that’s taken a very long time: CSS2.1.

CSS2.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. Well, it’s been in development for over 10 years, and it has only just become a candidate recommendation (23 April 2009).

Even then, it still doesn’t have two browsers completely supporting it. Only Internet Explorer 8 supports the full CSS2.1 spec.

Did that stop you from using CSS2.1? I suspect not. Will that stop us from using HTML5? It certainly shouldn’t. HTML5 is available and ready to use today.

In fact, the really important HTML5 date is October 2009. This is the last call for the HTML5 working draft. That means that issues with the spec, enhancements, bugs, anything – it all needs to be in and submitted and written into the spec for October (although it can go through reiterations, this is the main deadline).

The Web Hypertext Application Technology Working Group (WHATWG) is completely open for anyone to contribute their ideas and suggestions. You can sign up to the mailing lists. You can communicate directly using IRC. And there’s even a complete log of all the IRC history. It’s all available from whatwg.org.
HTML5 in five seconds

So how do you get your markup to validate as HTML5? It’s super 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 is doing it already. Check out its homepage, written all in one line:
<!DOCTYPE html><head><title>HTML5 – Google Search</title><script>…
Ironically, Google’s search page and listings don’t validate because of their use of invalid tags – font element for instance – and a number of other errors. But that doesn’t matter, because they can take advantage of the HTML5 parsing rules with that doctype (for example: no type attribute on the script element).

Although that’s all you need for HTML5 to be triggered, there’s a lot more to HTML5 for you to play with. If you want something a little fuller, here’s a typical boilerplate for HTML5, which includes the IE shiv (which I’ll discuss later) and default HTML5 block styles:
<!DOCTYPE html>
<meta charset=utf-8 />
<title>HTML5 complete</title>
<!–[if IE]>
<script src=”http://html5shiv.googlecode.com/svn/trunk/html5.js”></script>
article, aside, figure, footer, header, hgroup, menu, nav, section { display: block; }
<p>Hello World</p>
A note about the style and script elements in HTML5: 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.
More 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 divs 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? HTML5 gives us exactly that.

One of the biggest assets to us authors of HTML5 is the new semantic markup. There’s an arsenal of new elements that has been added to HTML5, and because of the ‘pave the cowpaths’ approach, these can be used by the browsers today (although some might need a little bit of prodding from JavaScript).

Here’s a non-exclusive list of the new HTML5 elements that are available:
1) Block structure

article represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable. This could be a forum post, blog post, newspaper article, a 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, eg a pull quote or a sidebar.
  • footer is 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 mark up 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 mark up the author’s name and the time of a comment placed on a blog post, for example.
  • nav is used to wrap major navigation blocks, such as table of contents, pagination links and breadcrumbs. Note that the nav element should be used for links that navigate around site, i.e. inappropriate for a list of sponsor links.
  • section is 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.

2) Inline semantics

  • details is used to include additional info that the user can obtain on demand. An open attribute on the element determines whether its contents can be seen, and it can be toggled by the user or by JavaScript.
  • figure is 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, eg to mark the terms the user was searching for.
  • time is 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.

3) Interactive elements

The following elements include DOM interface methods that allow them to function correctly. So 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 and video are both types of media elements. They enable you to embed audio and video directly into the browser without any need for plug-ins. However, where support is lacking in the browser, best practice suggests that you should fall back to Flash plug-ins. You can either let the browser render the chrome for the element, or take control via JavaScript to create a bespoke interface.
  • source is a child element to audio and video. It enables 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 is a 2D drawing element that can be accessed using JavaScript to render graphics on the fly – for example, for games, graphs or animations.

4) Compatibility

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 browsers 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, its 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>
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 causes the DOM to render incorrectly. However, Firefox 2 had its A-grade support dropped last year, and Firefox has a very solid upgrade path (hence why they’ve been dropped from A-grade support in the first place).

Camino has version 2 in beta, but it hasn’t been released just yet (and arguably, it’s not an A-grade browser). However, there are a few ways to fix Firefox 2 and Camino 1 and you can read about them here.
Fixing Internet Explorer

So, Internet Explorer is problematic. What’s new, right? The fix is actually incredibly simple, and if you’re using any of the new DOM APIs or HTML5 JavaScript APIs, the requirement for JavaScript is justified.

Sjoerd Visscher first posted about this solution whereby Internet Explorer is able to style any element so long as you run the following code:
Now myelement can be styled using CSS in Internet Explorer.

We also have an HTML5 shiv to enable all the HTML5 elements for Internet Explorer.

So long as this script is included in the head element, then you’ll be able to style the document correctly:
<!–[if IE]>
<script src=”http://html5shiv.googlecode.com/svn/trunk/html5.js”></script>
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.
Default HTML5 styles

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,
figure, aside, footer {
display: block;
But wait: it’s more than just markup. HTML5 is much, much more than just markup changes.

There’s also the Web Forms 2.0 spec in HTML5 which means we don’t have to use JavaScript to do the basic form validation that we’ve all repeated time and time again. You’ve also seen how the audio and video elements can be interactive. They expose a DOM interface that JavaScript can interact with. Included in the HTML5 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 HTML5 JavaScript APIs include:

  • Drag and Drop – native JavaScript dragging, which also works across browser windows. Currently available in IE8, Firefox 3.5 and Safari 4.
  • Inline editing – enabling the user to edit content visibly on the page without an editor; the changes can then be used as the input to a CMS.
  • History API – to support Ajax-based applications and saving states in the history to move back and forth between.
  • Cross-domain messaging – allowing messages to be communicated across different domains. This is available in IE8, Firefox 3.5, Safari 4 and Opera 10.
  • Offline applications – enabling users to continue to use your web application even without a web connection. Available in Safari 4 (and iPhone Safari) and Firefox 3.5.

The specs are changing all the time, leading up to the last call (in October 2009). Some of the other interesting JavaScript APIs include:

  • Local storage – two types of storage, key/ value pair and SQL based to store data associated with your application.
  • Web workers – basically threading for JavaScript.
  • Geolocation – an API to retrieve the latitude and longitude.
  • New selector API – document.querySelectorAll uses CSS syntax to find elements in the DOM.
  • Web sockets – for TCP/IP type socket communication.

HTML5 is here to stay. 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 and integrated into your cutting edge applications.

So go play!


0 Responses to “/Culture/ HTML5 today!”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: