Jeffrey Way - Decoding HTML5

This is that chapter you typically 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 what you had in mind when you picked this book up.

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 the release of HTML 4.01, at the tail-end of the nineties.

• 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.
• HTMLWG Once the W3C finally recognized that XHTML 2.0 was not the future, they indicated that they wished to work with the WHATWG on development of what would eventually become HTML5. They chartered the HTMLWG for this purpose.

If that still sounds confusing, don't worry. Continue reading for the full story.

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 (for the most part), and not including 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?

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 of glaring issues.

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

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 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

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.

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? For all intents and purposes, they were ignoring the current web, and the demands of its developers, in favor of a pure XML-based approach. It simply wasn't practical to expect such a huge transition.

XHTML2 was never finalized.

(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.

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.