The Story of HTML5

As you know, HTML is the language you use to write web pages. The basic idea of HTML—that you use elements to structure your content—hasn’t changed since the Web’s earliest days. In fact, even the oldest web pages still work perfectly well in the most modern web browsers (including several browsers that didn’t exist at the time, like Firefox and Chrome).
Being old and successful also carries some sizable risks—namely, everyone wants to replace you. In 1998, the W3C stopped working on HTML and attempted to improve it with an XML-powered successor called XHTML 1.0.



XHTML 1.0: Getting Strict

XHTML has most of the same syntax conventions as HTML, but it enforces stricter rules. Much of the sloppy markup that traditional HTML permitted just isn’t acceptable in XHTML.
For example, suppose you want to italicize the last word in a heading, like so:
<h1>The Life of a <i>Duck</i></h1>
And you accidentally swap the final two tags:
<h1>The Life of a <i>Duck</h1></i>
When a browser encounters this slightly messed-up markup, it can figure out what you really want. It italicizes the last word, without even a polite complaint. However, the mismatched tags break the official rules of XHTML. If you plug your page into an XHTML validator (or use a web design tool like Dreamweaver), you’ll get a warning that points out your mistake. From a web design point of view, this is helpful it lets you catch minor mistakes that might cause inconsistent results on different browsers, or might cause bigger problems when you edit and enhance the page. At first, XHTML was a success story. Professional web developers, who were frustrated with browser quirks and the anything-goes state of web design, flocked to XHTML. Along the way, they were forced to adopt better habits and give up a few of the half-baked formatting features found in HTML. However, many of XHTML’s imagined benefits—like interoperability with XML tools, easier page processing for automated programs, portability to mobile platforms, and extensibility of the XHTML language itself—never came to pass. Still, XHTML became the standard for most serious web designers. And while every one seemed pretty happy, there was one dirty secret: Although browsers understood XHTML markup, they didn’t enforce the strict error-checking that the standard required. That means a page could break the rules of XHTML, and the browsers wouldn’t blink. In fact, there was nothing to stop a web developer from throwing together a mess of sloppy markup and old-fashioned HTML content, and calling it an XHTML page. There wasn’t a single browser on the planet that would complain. And that made the people in charge of the XHTML standard deeply uncomfortable.

XHTML 2: The Unexpected Failure

The solution was supposed to be XHTML 2. It was set to tighten up the error-
handling rules, forcing browsers to reject invalid XHTML 2 pages. XHTML 2 also
threw out many of the quirks and conventions it had inherited from HTML. For example, the system of numbered headings (<h1>, <h2>, <h3>, and so on) was superseded by a new <h> element, whose significance depended on its position in a webpage. Similarly, the <a> element was eclipsed by a feature that let web developerstransform any element into a link, and the <img> element lost its alt attribute in favor of a new way to supply alternate content.
These changes were typical of XHTML 2. From a theoretical point of view, they were cleaner and made more sense. From a practical point of view, they forced everyone to change the way they wrote web pages (to say nothing of updating the web pages they already had), without adding new functionality to make all the work worth while. And along the way, XHTML 2 dumped a few well-worn elements that some web designers still loved, like <b> (for bold text), <i> (for italics), and <iframe> (for embedding one web page inside another).
But perhaps the worst problem was the glacial pace of change. Development on
XHTML 2 dragged on for five years, and developer enthusiasm slowly leaked away.

HTML5: Back From the Dead

At about the same time (starting in 2004), a group of people started looking at the future of the Web from a different angle. Instead of trying to sort out what was wrong (or just “philosophically impure”) in HTML, they focused on what was missing, in terms of the things web developers wanted to get done.
After all, HTML began its life as a tool for displaying documents. With the addition of JavaScript, it had morphed into a system for developing web applications, like search engines, e-commerce stores, mapping tools, email readers, and a whole lot more. And while a crafty web application can do a lot of impressive things, creating one isn’t easy. Most rely on a soup of handwritten JavaScript, one or more popular JavaScript toolkits, and a web application that runs on the web server. It’s a challenge to get all these pieces to interact consistently on different browsers. Even when you get it to work, you need to mind the duct tape and staples that hold everything together.
The people creating browsers were particularly concerned about this situation, and a group of forward-thinking individuals from Opera Software (the creators of the Opera browser) and the Mozilla Foundation (the creators of Firefox) lobbied to get XHTML to introduce more developer-oriented features. When they failed, Opera, Mozilla, and Apple formed the loosely knit WHATWG (Web Hypertext Application Technology Working Group) to think of new solutions.
The WHATWG wasn’t out to replace HTML, but to extend it, in a seamless, backward compatible way. In fact, the earliest version of its work had two add-on specifications called Web Applications 1.0 and Web Forms 2.0. Eventually, these standards evolvedinto HTML5.