The various reports and discussions around HTML5 in the past year have been a source of much confusion. In order to do my bit to help clear that up, I thought I’d offer a broad overview of what it is, and what it represents for the web.

Should I care and why?

Yes. But why? Well, there are a few ways to answer that, which I’ve tried to elaborate for you below.

Process

One of the biggest differences between HTML5 and previous markup specifications, indeed between HTML5 and any other web standard, is the process that is being used to put it together. Generally web specifications are created by the W3C using working groups who draft specifications in a closed process that has left some people dissatisfied.

In a break with this convention, HTML5 has been developed externally to the W3C by a group called the WHATWG. This group developed as a response to dissatisfaction with the W3C’s direction with XHTML and “…apparent disregard for the needs of real world authors.”

Although still driven in the main by browser vendors, WHATWG does use a much more open process, developing the spec for HTML5 through a mailing list that anyone can participate in. This has lead to a process that is faster and better supported by the web development community as a whole. So much so that HTML5 has now been formally adopted by the W3C to the detriment of XHTML2, their chosen successor for existing markup standards.

The other key aspect of the process is that HTML5 is being implemented incrementally by browser vendors. So although the projected completion date for the specification is 2022, there are aspects of HTML5 available right now and more will become available as time goes on.

Applications

The explicit focus of HTML5 is on applications. HTML’s origins as a document markup language are in stark contrast to the rapid developments in functionality and complexity present in many modern day web applications. HTML5 represents an attempt to go beyond documents and create a markup specification for structuring applications as opposed to documents.

We can see this in many of the new elements being created within HTML5, such as section, nav, aside. These are based on common conventions that are currently implemented by using class and id attributes on HTML elements like div, ol, code which all pertain to elements of a written document. So where we might currently have

<div class="article">
  <div class="section">
    <h2>This is a section of a larger document</h2>
    <p>Here is some text in this particular section</p>
  </div>
</div>

in html5, we would structure it something like the following;

<article>
  <section>
    <h2>This is a section of a larger document</h2>
    <p>Here is some text in this particular section</p>
  </section>
</article>

Perhaps more significant are the number of new APIs being specified, which will allow greater access to browser functions for web developers, as well as extending browser functionality to allow web applications to take on more of the advantages of desktop apps.

Best known is canvas, a 2d drawing api, which is already implemented in recent versions of Firefox, Safari, Chrome and Opera. However, just as significant are APIs that will allow offline web apps, drag and drop, video and audio controls, cross document messaging and text editing. Again, like the new elements, these are things that currently exist in web apps, but mainly through cumbersome and insecure javascript implementations that often are highly non-standard.*

Openness

HTML5 is open in two ways; firstly its open in terms of how it’s details are discussed and written. However it’s open in much broader sense; no one person owns HTML5, or indeed CSS3, or Javascript. This is important as we consider how the web is progressing today. Basically, if you wish to make a complex web application, you have a few choices; web standards technologies, Silverlight, Flash, Java Applets. Ok, that last one was a joke, but you get the picture. But really these choices are just two; open web standards that are not the property of a single company, or proprietary technology which is owned by one company. I realise there are good arguments on either side of that particular debate, which I don’t have time to elaborate here, but my personal choice is for standards, mainly as I feel more confident that more of my target audience will be able to access them.

So, there are a few reasons why you should pay attention to HTML5. To be honest, before I took the time to investigate it for myself, I wasn’t convinced, but I’m glad I did. HTML5 is not perfect, but that’s the point. It’s the first web standard that admits of its own imperfection, makes room for change and addresses the realities of modern web development, which overall seems like a good thing to me.

• Restricting your controller functionality in this way naturally prevents you from building bloated controllers
• It ensures that the layout of your code doesn’t become too obfuscated
• It allows you to make calls without having to specify your controller action explicitly in the request (as you do in a normal HTTP GET request).

Basically RESTful development is all about nouns, and a complete RESTful design will have the entire functionality of the website broken down into nouns that can be manipulated exclusively by CRUD operations. Each noun will be a controller (and often but by no means always it will also be a database model) and each controller will have up to four functions to represent each CRUD action.

For example take very simple online CMS with a database of users who can log in and change the text on various pages. A RESTful design might look something like this:

Noun – ‘user’
POST – Create new user
GET – Read user details
PUT – Update user
DELETE – Delete user

Noun – ‘page_text’
POST – Create new text
GET – Read text
PUT – Update text
DELETE – Delete text

As you can see, RESTful design where the nouns are models is very very straightforward and logical. But what about allowing the users to log in? We don’t have a ‘login’ model in the same way as the users and page_texts, but we can represent the action in a very similar way:

Noun – ‘login’
POST – Log a user in (create a ‘login’)
DELETE – Log a user out (delete a ‘login’)

And if we wanted the ability to preview new text before saving it:

Noun – ‘preview’
POST – Show (create) a ‘preview’

Now everyone knows how to send GET and POST requests but what about PUT and DELETE? Despite being part of the HTTP protocol since day one they are surprisingly under-used. All modern server-side languages should accept these as valid HTTP methods but in practice the PUT method is rarely used for an update operation as this can be distinguished from a create operation simply by the presence of a key relating to the noun that will be updated:

POST request with no key – Create
GET request with key – Read
POST data with key – Update
DELETE request with key – Delete

It really is that simple. It doesn’t take much thought to break down any operation into one or more nouns with one or more of the CRUD operations being performed on each. Do that and you’ll be programming RESTfully in no time.

We’re proud to announce that as of today one of our developers, Lee Hambley has taken over maintenance of capify.org. For many people involved in Ruby on Rails development, Capistrano is a vital tool, making the whole process of maintaining production environments that much simpler, by automating and combining many of the more laborious and repetitive tasks involved.

Having been an active member of the user group for sometime, when Lee heard the sad news that original developer Jamis Buck had to give up maintenance of the project, he offered to take it on.

I’m really excited about working with the other contributors to maintain and improve Capistrano and it’s documentation, watching the project gain speed now the code is a little bit more free is going to be awesome. – Lee

He will be hosting and maintaining the Capify.org site, as well as consolidating and hopefully coordinating new developments to the gem when a new code maintainer is selected. Find out more about Capistrano by visiting capify.org, or the Capistrano google group.