Posts Tagged ‘html5questions’

HTML5 is not ready yet – and will never be (and that is a good thing) – HTML5 Question #1

Wednesday, March 14th, 2012

One of the big questions I repeatedly got at events lately is this:

Is HTML5 ready yet?

The Roscommon Spaghetti Incident

The answer is no, because HTML5 is not a bowl of spaghetti that you know when they are ready by flinging them against the wall. HTML was never “ready” and will never be “ready”. It can be “the right choice” and it will be “an exciting opportunity”, it might also be “a dirty hack that works right now” or a “semantically valuable resource that can be converted to whatever you want”.

You see, even HTML4.01 or XHTML for that matter was never “ready”. Sure, the standard was agreed on and you could put in your project deliveries that your web site will be compatible with it, but in most cases this was a lie.

Standard compliance on the web is a means to an end. It made it easier to track mistakes and it made your work understandable by other developers but when it comes to delivering web products, it had not much impact. As web developers we were constantly asked to build interfaces and apply designs and interactions that were never defined in the standard. Which is why we had to find ways to do that which in a lot of cases meant abusing the standard.

We used spacer GIFs and   for padding and margins before CSS got support, we used tables for layout, we used image maps, we used image replacement, we used HTML generated from JavaScript for different browsers and whatever it took to get the best out of what we had in order to achieve the goal we set ourselves.

The goal was always the same: deliver the best possible experience in an unknown, always changing environment.

You don’t know what browser in what setting on which operating system with which security settings the end user has. You also don’t know what ability and connectivity the end user has. An HTML5 app is meant to run on a desktop with 1440 resolution, quadcore processor and lots of RAM on a 10mbit line but also on an old smartphone in the middle of nowhere with a flaky connection. And this is where HTML/CSS and JavaScript excel: you can build apps and sites that adapt to the needs of the environment they run in. This always meant a mix of various web standards and approaches.

The big issue we have now is that with a lot of HTML5 marketing this goal has been washed out and people expect more control from HTML5. The incredibly brain-dead message of “HTML5 is the Flash killer” (yes, I said it) clouds all of our judgement and stands in the way of great web applications. In my book, Flash doesn’t need killing at all.

What needs killing is the close-minded limited way we think about web applications. Flash gave people the impression that they can control the web and define what the end user sees. This is limiting the web and does a disservice to your product. When building web applications you should focus on reaching as many people as possible and not force-feed your design or interaction to all and deliver an agreement that leaves everybody unsatisfied. The recently released Web App Field Guide by Google brings it to the point: HTML5 has enabled developers to break free of the limits they were used to when building web applications.

HTML5 is the evolution we needed in web technology to build apps instead of documents. HTML4 was not the right technology for that and XHTML was a bust from the very beginning as it was too rigid for the web. We now have ways to store information on the computer, we have access to multimedia and we can create visuals in the browser. HTML5 is not just markup or “watered down XML”, it includes JavaScript APIs and defines how a browser should behave if it wants to be called an HTML5 compliant browser.

The main difference between HTML4 and HTML5 is the direction of innovation. In the HTML4 world we had a standard that was inadequate to what we needed to build. That’s why browser vendors build their own extensions on top of it and created a total mess for developers. In order to achieve our goal we had to write code for each of the browsers out there, rather than writing HTML. This was awful and caused a lot of people to chose the simple way out and write exclusively for one browser. In the past this was Internet Explorer 6 and this is why we now have a lot of government and enterprise IT environments that don’t upgrade to newer browsers. This holds us back.

HTML is now a living standard. This boggles the mind of a lot of people – how could a standard be living? Well, to me, this makes a lot of sense. The needs of the web are constantly changing. A few years ago nobody predicted – least of all the standards bodies – that we will consume the internet on mobile devices with touch interfaces. What will happen in the nearer future? Who knows? Face and motion recognition?

HTML5 is defined by browser makers tinkering and innovating and feeding back to the standard. Then other browser makers weigh in and we make it an agreed standard. This avoids the issue of developers having to build things for browsers and it means the standard will not fall behind. The main power of the internet is that you don’t need to write the same app several times for different environments and by agreeing amongst browser makers we make sure that there will not be a new IE6 situation.

So no, HTML5 is not ready and will never be – and that is a good thing. We have a standard for the web with all its change and adaptation and not a software standard that expects 5 year turnaround times in innovation.

Discussion on Google+Discussion on Facebook