HTML5 - everyone seems to think its the solution we've been waiting for. But is it? What if we were to think the unthinkable and imagine what a really good web development system would look like?

To quote Marvin the Paranoid android about a Magrathean sunset that Arthur finds magnificent:

"I've seen it. It's rubbish."

Mark-up magic?

It is odd that a few minor additions to a mark-up language - something that isn't really supposed to be particularly dynamic or particularly about programming - has so many developers falling over themselves to embrace a wonderful new future. It even has Microsoft rejecting its flagship web app creation tool, Silverlight, in favour of HTML5/CSS/Javascript.

While there some very good things in HTML5 both welcome and very overdue this is not the nirvana we are looking for. To see that this is true you just have to sit down and list the sort of facilities developers are looking for when creating an app of any kind and then imagine what HTML5 would look like if it was designed by a programmer.

You need to keep in mind that HTML5 is a mark-up language that was introduced to allow easy page layout. Over the years it has developed, but the page designers and stylists have had more input into what it has become than programmers. We have mostly have had to put up with small additions and modifications that didn't get in the way of keeping things simple.

One of the big changes in thinking about HTML has been its gradual elevation from a mark-up language concerned with the way things look on the page to a semantic markup language concerned with marking the meaning and intended use of a page entity and leaving how things look to CSS. This is a wonderful idea because it means you can change the look of something very easily and impose a central control on presentation.

From the programmer's point of view, however, the change has brought little payoff. For example, mark up a menu as a menu by all means and then control how it looks using CSS, but to programmers menu semantics means what happens when the menu is clicked and in this our options are limited. If we want any special behaviour then we need to turn to Javascript which isn't exactly well integrated with either HTML or CSS.

Javascript

Javascript is really the key issue and now is a good time to discuss it.

The first thing to say is that it isn't really a first class language in the same league as Java, C# or C++. So how is it that I'm stuck with it?

You could argue I'm not but in practice, if I want my app to work without fuss I am. Don't misunderstand me - I happen to like Javascript a lot - but it has progressed little over the time and for all its nice features it still doesn't have the infrastructure and support I need from a modern language.

Encountering Javascript is like being in a time warp. And in any case why is it I am stuck with Javascript on the client, some other language on the server and mostly likely another language on the desktop? Surely as a programmer I could be given the right to choose the language I want to use in all three environments?

The fact that I can't is a good indication of how left out of the development of HTML programming concerns really are.

Where are custom tags?

Let's now look at how we are constrained by the need to maintain the view that HTML/CSS is for design.

New in HTML5 is the Canvas object - can you really believe we have had to wait so long for a basic graphics object?

Now consider the following problem - how do you implement a new UI control using HTML5? You can do it in all sorts of round about ways - most obviously using Canvas and Javascript - but where is the support for new controls in HTML?

Why can't I extend HTML with a new custom tag?