The IT industry has grown and flourished because of standards. Standards enable people to work together, enabling products to interoperate, allowing large solutions to be built from smaller parts, giving customers choices, fostering competition, pushing the limits of innovation, and ultimately making the world a better place. The web, in no small part, has also benefited from the existence of standards.
I first started working on the web in 1994. I was a student then, but in my own time, I was running a website. I picked up web skills, not just about running web servers, but also about authoring web pages. My favourite web editor at that time, and it still is today, is vi. Vi, if you don’t know, is that screen-oriented mode-based text editor found in most Unix operating systems. Many newbie Unix users are horrified by vi. It makes you think in command mode and insert mode, and that overwhelms many of them. I don’t use Dreamweaver or any fancy WYSIWYG web authoring software. It’s just vi for me.
Using a text editor meant that I had to code HTML by hand. I had to learn about HTML tags, and I had to know how to use them. It wasn’t difficult. But over time, I begun to get frustrated. It’s not because of having to write HTML by hand. The problems I experienced are the same if I had used WYSIWYG web authoring tools. You see, given the same web page, it’s possible that the contents get rendered differently depending on which web browser you used.
In the early days, there were just two web browsers. You either used NCSA Mosaic or Netscape Navigator. Their capabilities were basic, and users’ expectations were lower. Fast forward to the big Internet boom. The web was on all sorts of devices, and there were so many types of web browsers. Every web browser behaved slightly differently.
The problem actually begun with HTML. You see, in the early days, people were not writing HTML properly. People were also abusing HTML to do things it wasn’t meant to do. Web browsers, for their part, tried to be very accommodating by rendering what they believed was the web author’s intention. Web browsers had to do that, because if they dutifully broke the web page because the HTML was not properly written, users would blame the web browser. That was the era up to HTML 4.01. Oh yes, HTML has version numbers. Someone did write specifications. The trouble is people did not read them. People kept breaking the rules.
The inconsistent behaviour was very frustrating for me. I minded very much how my web pages look, and in particular that they should look exactly the same on every device, with every web browser. It makes the web authoring job that much easier if I can be assured that if the web page looks alright in Firefox, then it ought to be so in Microsoft Internet Explorer. It ensures that contents will be consistently rendered.
Of course, in the early days when there were only two or three major web browsers, you could design your web page to cater to the idiosyncrasies of each web browser. You could individually test your web page in each of those web browsers. But this just could not continue when many web browsers appeared on too many web-enabled devices.
That’s why we need standards. The old standards were broken, because no one cared, the implementations were broken, and they weren’t catching up to the needs of the web. The W3C started work in 2004 to create new standards. It was to be called HTML5.
HTML5 (HTML 5.0) is actually not yet a standard. The road to standards ratification takes a long time. HTML5 was designated a candidate recommendation in December 2012, but it’s only expected to be released as a final recommendation by the end of 2014. Yes, HTML5 is not quite yet an official standard.
However, all major web browsers have already implemented many, if not most, parts of the HTML5 specifications. If you are interested, you can load up html5test.com in your browser to see how it fares. The following table summarises some of those scores (on Mac OS X).
| Browser | Version | Score |
|---|---|---|
| Google Chrome | 35.0.1916.114 | 507 |
| Safari | 7.0.4 (9537.76.4) | 415 |
| Firefox | 29.0.1 | 467 |
Many forward looking websites have also started to adopt HTML5. There are really good reasons to do so. HTML5 ensures the highest level of consistency across web browsers that implement HTML5. All the modern desktop web browsers already do that. Mobile web browsers are pretty much all onboard with HTML5 too.
Another advantage of HTML5 is its cleaner and simpler code. It’s actually easier for humans to read HTML5, as it is for machines to process the code. HTML5 also paves the way for new web requirements with support for accessibility features, video, audio, local store beyond simple cookies, better interactivity, and canvas support that will eradicate the need for Flash.
What about web browsers which don’t support HTML5? Well, HTML5 was designed so that it still displays alright on older web browsers. A webpage written with HTML5 will still render reasonably well on older web browsers.
HTML5 will enable web developers to focus their time building better apps, and spend less time worrying about interoperability issues and supporting browser-specific problems. HTML5 is easy to pickup. There’s really little reason not to go with HTML5, especially on new projects. Yet, ironically, we still find many new websites being built on outdated standards.
That HTML5 will be ratified is a matter of time. All the companies behind the major web browsers are already firmly supporting HTML5. Everything about HTML5 is good, and there’s little downside to it.
Why then are web developers not excited HTML5? Why isn’t every one of them jumping onto the HTML5 bandwagon? Why are new websites still developed based on old specifications?
I think, the web has brought up a generation of web developers who have gotten too lazy to write proper code. They have been getting away with broken code for a decade. Their broken code still somewhat works, after all. Why bother with specifications? Just so long as their stuffs just passably work?
Sometimes, it’s the tools that get the blame. It’s an easy excuse, but one that’s partly true. You see, the tools are after all written by developers too, and these other developers are also guilty of breaking HTML5.
For example, the WordPress blogging software generates HTML that breaks HTML5 validation. A WordPress theme designer can take care to produce HTML5 valid code, only for the ultimately generated webpage to fail validation because of broken parts spewed out by WordPress. Yet, there are ways to fudge the WordPress output to pass validation without hacking the WordPress code itself.
That’s what I found myself doing. I fudged around WordPress through my custom theme without hacking WordPress itself. The HTML5 conformance bothered me even though what’s broken had nothing to do with me. It does seem like needing to put in quite a bit of extra effort, but the benefit is that the site will render much more consistently across multiple browsers and devices.
Have you started on HTML5?
View Comment Policy