A Brief History of HTML5

This is that article you generally skip over. It’s the one where I don’t detail an ounce of code, but instead describe the important events that lead to what you now recognize as HTML5. Some of us find this stuff interesting, but, certainly, a history lesson may not be your idea of a good time.

…Wait – you’re still here? Let’s get on with it then.

We won’t travel as far back as the beginning. That’s an entire book on its own. Instead, we’ll rewind the clock to to the release of HTML 4.01, at the tail-end of the nineties.

What’s the Difference Between the W3C, WHAT WG, and HTML WG?

• W3C – A community with the sole purpose of working to develop web standards.
• WHATWG – Formed after various members of the W3C became agitated by the direction being taken with XHTML 2.0. They preferred a different, less drastic approach, where the existing HTML was extended.
• HTML WG – Once the W3C finally recognized that XHTML 2.0 was not the future, they indicated that they wished to work with the WHAT WG on development of what would eventually become HTML5. They chartered the HTML WG for this purpose.

If that still sounds confusing, don’t worry; continue reading for the full story.

HTML vs XHTML

Right around the period that HTML advanced to version 4.01 (around 1998), the ground began to shift a bit. Developers started to talk about this next new thing the W3C was working on: XHTML, which stood for “Extensible Hypertext Markup Language.” This first 1.0 specification was more or less identical to HTML 4.01, other than the inclusion of a new MIME type, application/xhtml+xml.

Believe it or not, we’ve always been able to get away with omitting quotations around attribute values (mostly), and not self-closing tags. However, up until recently, it was widely considered to be a bad practice. For the youngsters among you readers, the reason why we viewed it as a bad practice is largely due to the popularity of XHTML.

Think of XHTML as your grandmother. When she comes to visit, she forces you to brush your teeth, stand up straight, and eat your peas. Now replace teeth, posture, and peas, with quotation marks, self-closing tags, and lowercase tag names.

Though I kid, mostly, we viewed XHTML 1.0 as a good thing – the next step. It required designers and developers to follow a set of standards when creating markup. How could that be bad? The irony is that, though we followed these new rules, the majority of us continued serving pages with the text/html MIME type, which meant that the browser didn’t really care how we created our markup. This way, XHTML could be opt-in.

So we were writing markup in a certain, strict fashion to pass XHTML validation that had zero effect or influence on the browser’s rendering. A bit odd, huh?

XHTML 1.1

This all changed with the introduction of XHTML 1.1 – a significant shift toward pure XML. With this release, the application/xhtml+xml MIME type was required. Sure, this may sound like the natural next step, in theory, but there were a couple glaring issues.

1. “Save to Disk”

First, Internet Explorer could not render documents with this MIME type. Instead, it would prompt a save to disk dialog. Yikes!

“I’ve also been reading comments for some time in the IEBlog asking for support for the “application/xml+xhtml” MIME type in IE. I should say that IE7 will not add support for this MIME type – we will, of course, continue to read XHTML when served as “text/html”, presuming it follows the HTML compatibility recommendations.” – Chris Wilson

2. Take No Prisoners

XHTML 1.1 was sort of like Professor Umbridge, from Harry Potter.

Secondly, XHTML 1.1 was sort of like Professor Umbridge, from Harry Potter: extremely harsh. Have you ever noticed how, if you leave off a closing </li> tag, the browser doesn’t flinch? Browsers are smart, and compensate for your broken markup (more on this shortly). While, these days, the community is beginning to embrace and take advantage of this truth, with XHTML, the W3C wanted to enforce XHTML’s stricter syntax. Though, up to this point, developers could get away with leaving off, say, the closing <head> or <body> tag, the W3C implemented a new fail on the first error system, known as draconian error handling. If an error was detected, the browser was expected to cease rendering the page, and display an error message, accordingly. Like I said: incredibly harsh for markup.

As a result, few of us ever used XHTML 1.1; it was too risky. Instead, we adopted general XML best practices, and continued to serve our pages as text/html.

XHTML 2

In their minds, the W3C was finished with HTML 4. They even shut down and rechartered the HTML Working Group, and transferred their focus to XHTML – or, at this point, XHTML 2.0.

XHTML2 was an effort to draw a line, fix the web, and right the wrongs of HTML. Though, again, this sounds fabulous, in truth, it angered much of the community, due to the fact that it was never intended to be backward compatible with HTML 4. In fact, it was entirely different from XHTML 1.1 as well!

Get where I’m going here? The W3C was essentially ignoring the current web, and the demands of its developers, in favor of a strict, potentially page-breaking XML approach. It simply wasn’t practical to expect such a huge transition.

XHTML2 was never finalized.

Fight, Fight, Fight!

(Okay, not as Fight Club as that.) Right around this time, the idea that, “Hey – maybe we should return to HTML and work off that” began to come up again. Work had begun on Web Forms 2.0, which managed to spark renewed interest in HTML, rather than scrapping it entirely for XHTML2. This notion was put to the test in 2004, during a W3C workshop, where the advocates for HTML presented their case, and the work they had already done with Web Forms 2.0.

Unfortunately, the proposal was rejected on the grounds that it didn’t fall in line with the original goal of working toward XHTML2. Needless to say, this rejection angered some in the group, including representatives from Mozilla and Opera.

The group consequently branched out, and formed the WHAT Working Group (or, “Web Hypertext Application Technology Working Group.”), after, for lack of better words, becoming pissed off at the way XHTML 2 seemed to be heading. Their goal was to keep from throwing the baby out with the bath water. Continue and extend development of HTML, via three specifications: Web Forms 2.0, Web Apps 1.0, and Web Controls 1.0.

The Two Golden Rules

This new group would embrace two core principles:

1. Backward compatibility is paramount. Don’t ignore the existing web.
2. Specifications and implementations must match one another. This means that the spec should be incredibly detailed (hence, the 900 pages).

“The Web Hypertext Applications Technology working group therefore intends to address the need for one coherent development environment for Web Applications. To this end, the working group will create technical specifications that are intended for implementation in mass-market Web browsers, in particular Safari, Mozilla, and Opera.” – WHATWG.org

Parser

Don’t underestimate how significant an achievement this was.

While XHTML 2.0 intended to enforce perfect XML, the WHAT Working Group instead took it upon themselves to document exactly how HTML is, and should be parsed. – a five year task!

Remember when we discussed how browsers do a great job of compensating for your broken markup? The interesting thing is that, before the creation of the WHAT Working Group, there wasn’t any specification that provided instructions to the browser vendors for how to deal with errors. This naturally leads up to the question: how did the browsers match one another’s error handling? The answer is through tireless (though essential) reverse engineering. Firefox, Safari, and Opera copied Internet Explorer’s implementation, and Internet Explorer reverse engineered Netscape handling.

Over the course of five years, the WHAT WG charted out what’s now referred to as the HTML5 parser. Don’t underestimate how significant an achievement this was. Today, all modern browsers parse HTML according to the guidelines of this specification. Though perhaps not as sexy as, say, canvas, the HTML5 parser is a massive achievement.

A Line in the Sand

As you might expect, an imaginary line was drawn in the sand. You’re either for XHTML2, or (what would eventually become) HTML5.

Rather than a consensus-based approach, where members debated and voted on what they felt was best, the WHAT WG took a bit more of a dictator-like stance, with Ian Hickson at the helm.

Wait – Dictator!?

Don’t we usually try to over throw these power mongers?

Don’t we usually try to over throw these power mongers? What’s the deal? I must admit, on paper, it sounds awful, doesn’t it? Does one guy determines the future of the web? We prefer this system? Politically speaking, yes, a dictatorship may be a bad idea. But, when you think about it in terms of the web, imagine how much more quickly things can get done. When a community is as passionate as ours, things tend to move very slowly, as debates continue on and on…and on.

“The Web is, and should be, driven by technical merit, not consensus. The W3C pretends otherwise, and wastes a lot of time for it. The WHATWG does not.” – Ian Hickson

While discussion certainly (and rightfully) takes place at the WHAT WG, ultimately, Ian Hickson has his finger on the button (unless the group and community strongly disagrees with a particular decision. At this point, he can either be impeached (not as Bill Clinton as that), or, more often than not, he’ll re-evaluate and reverse his decision).

That said, it’s certainly not ideal. The W3C has its slow and steady consensus-based approach, which many still prefer. On the other hand, while the WHAT WG moves at a quicker pace, there certainly are hiccups. Then, when you combine the two groups, things can sometimes get a bit muddy!

The time Debacle

In October, 2011, Ian Hickson removed the <time> tag, and replaced it with a more general-purpose solution: <data>. In his own words:

Remember: you have much more control over the shape of the web than you likely give yourself credit for!

What he possibly didn’t realize was that much of the community did, in fact, use the <time> tag. Further, they (myself included) felt that, though more flexible, the proposed <data> tag was too ambiguous; <data> has as much meaning as a <span>, when it comes to semantics.

After a significant level of uproar from the community, the HTML WG announced that the <time> change must be reverted. They gave Ian a short deadline to make the reversal. Though not without additional layers of drama, the following month, <time> was reinstated.

This chain of events simply proves that, even though Ian has the right to propose these sorts of changes, the web community, as a whole – and, of course, the browser vendors – have quite a bit of control over the specification. There’s a difference between the spec creators, and the authors who integrate these new elements and APIs into their projects. If the authors don’t use them, they might as well be removed from the spec. Remember: you have much more control over the shape of the web than you likely give yourself credit for!

Sign up for the various mailing lists and be loud! Otherwise, folks like Ian won’t know if or how you use these new features.

“Is there any data showing how people actually use <time> in practice? i.e. is it actually giving anyone any of its hypothetical benefits?” – Comment by Ian Hickson

If you’d like to learn more about the <time> debacle, review the bug thread, and Ian’s Google+ post. They’re interesting reads, and aren’t nearly as black or white as you might think.

Back at the W3C…

Back to the W3C vs. WHAT WG feud. Well, it was less a feud, and more like two groups ignoring one another for a couple years.

As time progressed, it became clearer and clearer that XHTML 2.0 was not the solution.

While work at the WHAT WG progressed relatively quickly, work on XHTML 2.0 at the W3C was – how should I put this… – not going well (almost non-existent). As time progressed, it became clearer and clearer that XHTML 2.0 was not the solution (though it wouldn’t be fully dropped until 2009). In 2006, the W3C relented, and signaled that they were interested in collaborating with the WHAT WG on (what would be) HTML5. They chartered yet another group for this purpose: HTML WG, or the Hypertext Markup Language Working Group.

They intended to use the work of the WHAT WG as a basis for continued development of HTML. Weird, huh? Now we have two different groups: the W3C HTML WG and the WHAT WG. Technically, the W3C hadn’t yet given up on XHTML. Nonetheless, as part of the newly formed HTML WG, they renamed Web Apps 1.0 to HTML5.

“Apple, Mozilla, and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the less restrictive license on the WHAT WG site.” – WHATWG.org

Today

These days, the WHAT WG and W3C collaborate with one another on HTML5. It’s a bit of an odd relationship, but somehow manages to function, thanks to an endless supply of incredibly passionate activists.

This article is an excerpt from my upcoming book on HTML5 and its friends. Stay tuned to Nettuts+ for more information on the release date!