There’s a lot of buzz surrounding the HTML5 project at the moment and, ignoring the fact that I can never pass up an opportunity for a pun in a post title, I felt sufficiently opinionated on the matter to warrant posting my thoughts. As ever, anyone wishing to question my credentials or right to comment on this subject would do well to remember that I’ve been working on, in and around the web since 1995 and, whilst I’m certainly not considered one of the key speakers on the subject of markup languages I certainly have enough practical experience to justify the points laid out below.

I designed my first website in 1995. It wasn’t quite a “GeoCities special” but it did use HTML (mixed case non closed elements and unquoted attribute values of course), frames, tables for layout, inline JavaScript and all the other crimes of the mid 90′s web. I stopped just short of using Marquee – there are limits you know. It did not validate, was not accessible and looked pretty shoddy… but it worked.

Whilst at university I was being “taught” how to design web pages in WYSIWYG editors that used, tables for layout, inline JavaScript and produced reams of tag soup. Not compliant, not pretty and not accessible … but they worked.

First job out of uni and XHTML 1.0 was the markup to use, CSS was creeping in to play and every effort was made to build sites (and apps) in the most compliant method possible. Sometimes we succeeded. Sometimes we still dropped to tables for layout … and all of the sites worked (except in NC4 which just crashed).

Spool forward and we have AJAX, Web Services, RSS and XML at the forefront of web application interoperability, a veritable maelstrom of new technologies and standards and the websites?… they still work.

As you may have guessed the point behind this anecdotal history lesson is this:

Despite the shift in standards and implementations the web works, has always worked and will continue to work.

Right, some caveats. I’m not for a second suggesting that the standards as implemented are useless and I’m more than in favour of application of standards to those things to which it is reasonable and logical to apply them. XML and (to a lesser degree) CSS have benefited from clearly defined standards. XML can safely be interpreted (or rejected) based on a strict subset of the SGML schema making it a fantastic choice for connecting disparate processes or consuming information from 3rd party sources. CSS rendering has improved 1000% since the early noughties to the point that it is now possible to code a layout without hacks and have it work across most major browsers. This is only possible because CSS is so tightly specced and the community have maintained pressure on browser vendors to support this spec.

But let’s take a step back from this relentless push for standardisation. Yes CSS in the early years was a pain and support was patchy and vendor specific but we still managed to build stunning sites using on the bare minimum of workarounds. The CSS Zen Garden was full of them!

Working around the limitations of the platform is an unfortunate but inevitable part of what it means to be a web developer and no amount of markup standard changes is going to fix this. Why do I need semantic HTML5 elements in my markup that can be just as easily defined using good class names? Why the hell do I need a dedicated media tag when the existing object and embed hack works so effortlessly and has been employed to great effect all over the web?

but Rob, Embed and Object are non compliant … they’re broken and need fixing!

Really? has anyone told Chad and Steve this? How about the boys at the big G? Cos I’m pretty sure they just went ahead and made millions of dollars using “broken” HTML.

Because here’s the thing about the web – the core what has made it successful isn’t the way the information is presented – it’s the information itself. The millions of users of Facebook couldn’t care less if the app complies to standards provided it work in their browsers and on their phones. The web is all about function through content and it doesn’t matter in the slightest how badly broken the format of the content is – this has been tried and tested and proved time and time again.

So far as I’m concerned, XHTML 1.1 was the pinnacle of markup standards – it’s form was there for a tangible reason – to allow the web to be computer consumable as well as human consumable – to provide interoperability between the content and the function.

HTML5? Contains a lot of very modern enhancements to the language, most of which are already available in one form or another via one of the 3 legs of the web design stool. Designers and developers can implement pretty much anything they can dream of via DOM scripting and CSS. Indeed the web is full of highly successful sites that are doing just this. Why do we need to have one of the legs re-written or “improved” to duplicate functionality we already have?

I believe the HTML working groups have fundamentally lost sight of what make HTML so damn impressive – it’s simple and, by virtue of the inclusion of CSS, JavaScript and modern application servers, infinitely extensible. Trying to improve on it is simply going to end up bloating a perfectly straight forward and brilliant idea with features that are just not needed in the markup schema.

I’m going to finish with an idea that was pointed out to me by an ex colleague of mine – if you’re looking for something to fix it’s not the markup – it’s the protocol!

HTML is just fine as it is – HTTP needs some work to get it correctly implemented as per the spec but more on that later!