HTML5 is all the rage and yet it could be so much better. There is one single change that could be made that would make it much more useful and the change wouldn't break any existing web pages or applications.

So what is this magic ingredient?

Simply stop insisting that HTML is a markup language and allow it to evolve into an object-instantiation language.

That was easy - now let's look at what it all means and why it is such a good idea.

HTML Origins

HTML started out life having nothing at all to do with programming. It was intended as a markup language for hypertext documents, and it serves this role increasingly well. HTML5 takes this purity to the extreme and proclaims HTML as a "semantic markup language" leaving every aspect of what the page looks like up to CSS. This isn't a bad idea and the whole separation of concerns idea is an important and useful one.

We really shouldn't have any problem with semantic markup.

Enter the DOM

However, HTML has another role to play and it is this role that it really isn't serving at all well. As web pages became dynamic JavaScript got involved in the mix. What we needed was some way of allowing JavaScript to interact with the document as formatted by HTML. The solution to this problem was the invention of the DOM.

Basically the idea was simple - each HTML element corresponds to an object in an object tree that mirrors the nested structure of the document.

Simple and effective but for a small omission.

The DOM was, and is considered, to be a separate entity from JavaScript. It is part of the browser environment, and while a DOM object looks a lot like a JavaScript object the two are regarded as separate and very different. This has some advantages because it means that JavaScript can go off and play in other environments. You don't have to couple JavaScript and HTML as if they were one and the same thing.

But wait a minute - why not couple to the two together?

HTML as declarative UI language?

After all, every language needs some sort of UI technology and these days that technology is usually in the form of a markup language of one form or another. That is, a declarative UI creation language is a good and modern contrivance and every language either has one or could be made better by acquiring one.

So why not consider HTML to be not only semantic markup but the declarative UI language for JavaScript?

The first answer that occurs is that HTML is tied to the browser and this isn't always the host for JavaScript. It very nearly is the standard host but let's carry on and see where decoupling not HTML and JavaScript but the browser and JavaScript takes us.

HTML for object instantiation?

Suppose for a moment that we regard HTML as an object-instantiation language much like XAML or MXML. In this case we could do away with the DOM as a separate entity. The DOM would still be there and existing programs would carry on working but now HMTL elements would create real JavaScript objects corresponding to each element and nested according to the structure of the page.

That is when you write <Button> an instance of the JavaScript Button object is created. When you write:

<div>
  <Button></Button>
</div>

Then a JavaScript Div object is created with a Button object nested inside it as a property.

Attributes of each element also become properties of the instantiated object. So for example:

<Button class="MyButtons">

adds a class property to the Button and sets it equal to "MyButtons". Some attributes could, and should, be mapped to more general programming constructs. For example, the id attribute could be mapped to the instance name. So instead of having to go through the usual process of looking up a DOM element by id you could just write either:

MyButtons.property="mydate";

or if you want to avoid polluting the global name space:

document.MyButtons.property="mydate";

You could leave all of the DOM get functions and all of the manipulation functions they would still occasionally be needed and they would provide backward compatibility. 

The key idea is that if you wanted to continue to access the DOM as if it was a separate entity you could, but JavaScript programmers could also now start using DOM objects as first class JavaScript objects.

Now we come to the interesting part. As an object instantiation language HTML would now be extensible. If you included a tag on a page that wasn't part of the current standard:

<MyObject></MyObject>

then, as the page was read in, an instance of MyObject as defined in JavaScript would be created. You could specify its initial properties in the usual way via attributes and you could work with the object as a standard JavaScript object once the document was loaded.

The built-in objects would automatically render themselves to the page without the intervention of the programmer, or JavaScript, but a custom object could have a user interface component as well by using a Canvas object in its code. In other words, we really do have a way to create custom components.

This advantage alone is enough to make it worth making the change. If you look at the very complex ways in which custom controls are currently implemented in JavaScript - for example the way Microsoft is having to use custom attributes and separate DOM and JavaScript objects in WinRT - just making HTML an object-instantiation language is a great simplifier.