A Somewhat Sensationalized History of HTML5
We all know that HTML5 is the great hope for the Web—that’s what everyone tells us, so it must be true. It’s a beautiful shining Utopia where all citizens can browse in peace and harmony with pages loading smoothly and quickly, layouts looking the same across browsers, and not a plug-in in sight. That’s what they’d have you believe, anyway. There’s no doubt that HTML5 contains a lot of good, but it also contains a lot of . . . well, we’ll get to that. It’s time to learn the truth about HTML5.
How Architecture Astronauts and the W3C Tried to Kill HTML
Murder is always interesting, so let’s start there.
As you may know, HTML has a strange and sordid past. Between 1989 and 1990, Tim Berners-Lee wrote the first specification for the HTML language along with the client and server software to make it go. By 1996 he helped form the World Wide Web Consortium (W3C) to take over maintaining the HTML specification with input from browser manufacturers. At this point HTML would be pretty recognizable to any modern developer, and things were looking up.
In 1997 the W3C published a Recommendation for HTML 4.0. And two years later it was more or less completed in the form of HTML 4.01. (Don’t remember? Well, you were probably too busy worrying about the dreaded Y2K “bug” wiping out civilization.)
And that was pretty much it for plain old HTML.
So, what happened between HTML being “finished” in 1999 (in every sense of the word) and HTML5’s emergence today?
A long, aborted march to “XMListan.”
The W3C published the eXtensible Markup Language (XML) 1.0 specification in 1996 (www.w3.org/TR/1998/REC-xml-19980210), which it hoped would become a more flexible, machine-readable, stricter, and more extensible way to mark up documents and other data. And it was soon being used to do just that. But the W3C believed the Web itself would eventually move to XML.
One of the first baby steps toward making HTML a language machines as well as people could understand was XHTML—an XML formulation of HTML 4.
XML may sound foreign, but if you own or even subscribe to a blog, then you’re already using it. The RSS or Atom feed that blogs generate to syndicate their content is just one form of XML. If you look at the source of an Atom feed, you can see tags such as <author>, <published>, <category>, and <summary>. These are specific tags that accurately describe the content they represent. These tags aren’t part of a formal XML schema, but rather defined for that Atom format. This flexibility is just one example of the “extensible” part of XML that allows machines (parsers, RSS readers, and so on) to do interesting things with the content.
Now, imagine a world where we could describe our web pages in a similar way. That was the W3C’s plan for the Web—that all the future content on the Web should be described in more accurate terms than just <div>s, <span>s, <p>s, and <h1>s. And with XML, we could do it.
HTML would still exist as a legacy format. But the future was XML, baby.
XHTML Is Born, But What Does It Mean?
So if HTML was the past and XML was the future, how would we get there? With the interim step of XHTML.
By reformulating HTML 4.0 to stick to XML’s rules, XHTML was born. And in January 2000, having barely survived the Y2K apocalypse, the XHTML 1.0 spec was adopted as a W3C Recommendation (www.w3.org/TR/xhtml1/). We were on the road to XMListan.
In early 2002, Jeffrey Zeldman published the landmark XHTML article “Better Living Through XHTML” on A List Apart (www.alistapart.com/articles/betterliving/), describing XHTML as follows:
[T]he standard markup language for web documents and the successor to HTML 4. A mixture of classic (HTML) and cutting-edge (XML), this hybrid language looks and works much like HTML but is based on XML, the web’s “super” markup language, and brings web pages many of XML’s benefits, as enumerated by the Online Style Guide of the Branch Libraries of The New York Public Library.
Those benefits enumerated on the New York Public Library web site (http://legacy.www.nypl.org/styleguide/xhtml/benefits.html) included this:
The web is moving to XML, a powerfully enabling technology. Writing well-formed, valid XHTML pages is the easiest way to begin this transition. All it takes is learning a few simple rules of XHTML markup.
Web designers took heed of this call to begin the transition to XML via XHTML. In 2003 Dave Shea wrote a post called “Semantics and Bad Code” (www.mezzoblue.com/archives/2003/08/26/semantics_an/) where he said this:
The move from HTML to XML requires a huge shift in developer mindset. There are a lot of obstacles to overcome yet, not the least of which being solid browser support. We’ve only started down the road, and XHTML is how we’ll get there.
Shea’s view was a popular one at the time and certainly reasonable given our faith in the experts in the W3C.
But we never made it to XMListan. The car ran out of gas, the wheels fell off, and the engine exploded about two blocks down the road.
Draconian Error Handling (Or: Why Don’t I Just Punch You in the Face?)
Those of you building web sites back in the early ’00s may remember how important it was to have a valid web page. People even put dinky little “Valid XHTML” badges on their sites to show off just how forward-thinking they were. (They now put equally silly HTML5 badges on blogs—and books.) Design nerds would even run other people’s markup through the HTML validator and write a snarky blog post or e-mail if it failed. (Back then there was no Twitter to bitch publicly in 140 characters.)
Yes, having valid HTML is a good thing. But as web designers adopted XHTML, it became—in theory, if not practice—life or death. If you had so much as a single error in your XHTML, your browser would reach out and punch you in the face.
OK, Not Really. But Your Browser Would Punch You in the Face
Well, your browser would punch you in the face if you set up your server to tell the browser to adopt XML’s strict XHTML parsing rules, as Mark Pilgrim described in 2003 (www.xml.com/pub/a/2003/03/19/dive-into-xml.html), which hardly anyone did. Internet Explorer, right up to and including version 8, didn’t even support these strict XHTML parsing rules. (Ironically, IE9 now does, just as everyone stopped caring.)
Why didn’t anyone do it? Because they didn’t want to inflict the “draconian error handling” (www.w3.org/html/wg/wiki/DraconianErrorHandling) on their users (or themselves). And it really was draconian—one invalid character, such as & instead of &, would generate a fatal error that destroyed the entire page. And as a user, all you got was a hideous error message—no content, no nothing.
In light of this, the web standards community adopted the theory of XHTML without its harsh realities (or true XML nature), preferring to stick with the warm, cuddly, and vastly forgiving HTML parsing from the early days.
XHTML turned out to be a baby step toward a baby step. What should have been the first move toward a strict XML formulation of the Web, where we could use more descriptive (that is, semantic) tags, was just a step toward stricter, old-style HTML. It was two steps forward, one step back—back to the HTML the W3C had declared finished and was hoping to make obsolete.
Nevertheless, XHTML gave the web standards community something to, well, standardize on. It allowed everyone to be a bit more serious, and dare I say professional, about the markup we were writing. Jeffrey Zeldman wrote this on his blog in 2009 (www.zeldman.com/2009/07/07/in-defense-of-web-developers/):
XHTML’s introduction in 2000, and its emphasis on rules of construction, gave web standards evangelists like me a platform on which to hook a program of semantic markup replacing the bloated and unsustainable tag soup of the day. The web is better for this and always will be, and there is much still to do, as many people who create websites still have not heard the call.
For much of the ’00s, web sites built with web standards continued using XHTML. Designers got serious about separating presentation from content and tried to write more semantic markup. Using XHTML also triggered standards mode on the major browsers of the time. All good things.
But in the W3C’s grander scheme of things, XHTML ultimately proved to be a bit of a stepping-stone to nowhere.
But the Crazy Had Only Just Begun
XHTML served a useful purpose for web standards—albeit not the one originally intended. But now we step into the mad, mad, mad world of XHTML 2.0.
While we were all happily using and advocating XHTML in web standards land (though some stuck to HTML 4.0), the W3C was working on XHTML 2.0. Sounds like a harmless update of the 1.0 spec, right?
It wasn’t.
XHTML 2.0 was day zero for the Web. It wasn’t backward compatible with HTML or even XHTML 1.0. It was a whole new thang.
And nothing was safe.
Among the list of sweeping changes, plain old forms would be replaced with fancy XML-style XForms. Even the <img> element was on the chopping block at one point, as the W3C re-envisioned the Web as a more XML-ified place.
In an April 2011 blog post on software development, Joel Spolsky described what he calls “Architecture Astronauts” (www.joelonsoftware.com/articles/fog0000000018.html):
When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
These are the people I call Architecture Astronauts.
And XHTML 2.0 was a classic case of Architecture Astronauts at work.
Here’s how Bruce Lawson, HTML5 evangelist for Opera and author of Introducing HTML5 (New Riders, 2010), describes it (http://news.cnet.com/8301-17939_109-10281477-2.html):
XHTML 2 was a beautiful specification of philosophical purity that had absolutely no resemblance to the real world.
As far as HTML was concerned, this is what the W3C—the custodians of the language that underpins much of our relationships, business, and government in the 21st century—worked on from 2002 to 2006 over eight drafts. Not only would it have broken backward compatibility, it would also have sent all the talk of “forward compatibility” and “future-proofing” in the web standards community up in smoke. (You can read more about XHTML 2.0 in Wikipedia: http://en.wikipedia.org/wiki/XHTML#XHTML_2.0.)
While the W3C toiled away on XHTML 2.0, what did web authors, standards advocates, and browser vendors think of it?
Not much.
There was zero interest in implementing it. Even members of the working group were deeply unhappy with it. (See Jeffrey Zeldman’s thoughts on XHTML 2.0 in 2003 under “XHTML 2 and all that”: www.zeldman.com/daily/0103b.shtml.)
What was dopey about XHTML 2.0 wasn’t so much the spec itself (which would be fine if we could go back in time and rebuild the Web from scratch). It was the idea you could do something as revolutionary as breaking backward compatibility with millions of existing documents and create a whole new tier for the Web. But that was the path the W3C set itself on way back in 1998 (see it for yourself in “Shaping the Future of HTML” at www.w3.org/MarkUp/future/).
But what if the next evolution of HTML was just that—evolutionary rather than revolutionary? One that built on the world as it was and not some utopian world we could only hope for?
HTML5: A New Hope . . . We Hope
HTML5 began as a reaction to the W3C’s descent into markup madness. The problems with the W3C’s direction had not gone unnoticed.
In 2004, the so-called Web 2.0 movement took off in a big way, and web applications became a big deal. The Web was no longer just a collection of text and images on pages connected through links. It was becoming a platform for applications that could run anywhere, OS be damned.
Compared to the ’80s and ’90s, when your OS determined what applications you could use, running applications through a browser on any OS was a revolutionary idea.
No one really predicted this (certainly not the W3C), which isn’t surprising when you think how bad we are at predicting the future in general. (Where is my flying car?) We’re much better at reacting and evolving when the future arrives, which is what some people suggested we do with HTML.
In 2004, members representing Opera and Mozilla (with Apple “cheering [from] the sidelines,” as Ian Hickson recalls: www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/) presented an alternative to the W3C—a spec focused on web applications. (See the original “Position Paper” here: www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html.)
HTML needed to adapt to the future of web applications, rather than a utopian world of perfectly marked-up XML-ified web pages. So, this new group suggested an alternative direction for HTML based on backward compatibility: no more draconian error handling (the one-error-and-you’re-dead problem of XHTML as XML), new features for web applications, and an open process, which was in stark contrast to the way the W3C operates.
Essentially, the group’s philosophy was that HTML was here to stay, so we should concentrate on evolving it. (This may sound completely obvious now, but back then it wasn’t a view shared by the W3C.)
Anyway, the group members pitched their ideas to the W3C, and the W3C told them to go to hell. (Actually, they lost by only two votes—11 to 8 against. But this is the somewhat sensationalized history of HTML5.) WHATWG was formed after a proposal from Mozilla and Opera on “Web Applications and Compound Documents” was voted down on June 2nd, 2004 (www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html). Among the founding members of WHATWG were representatives from Apple, Mozilla, and Opera, including Hickson (http://en.wikipedia.org/wiki/WHATWG).
With the W3C being less than accommodating, those interested in evolving HTML and adding features for web applications, who were backed by (and worked for) the browser vendors, decided to press on and work outside the W3C. They formed the Web Hypertext Applications Technology Working Group (WHATWG) and set up shop at http://whatwg.org on June 4th, 2004.
And so the WHATWG was born. Here’s how Hickson explains it all (www.thechromesource.com/interview-html5-standards-author-ian-hickson/):
So [after the W3C rejection] we opened a mailing list called the WHATWG to continue work on Web Forms 2.0 in public, and later that year started a new draft called Web Applications 1.0 into which we put many features aimed at writing Web apps, including a new version of HTML that we jokingly called HTML5, and a bunch of other features that later became Web Storage, Web Sockets, Server-Sent Events, and a variety of other specs. [ . . . ]
Later, around 2006 or 2007, the W3C basically realized they had made a mistake, and they asked if they could work on HTML5 as well, so we renamed Web Applications 1.0 to HTML5, and the WHATWG and the W3C started working together. Web Forms 2.0 got merged into HTML5, and most of the bits of HTML5 that weren’t really HTML got split out into separate specs.
It’s ironic, isn’t it? The establishment (the W3C) was the utopian revolutionary, and the rebel outsiders (the WHATWG) were fighting for incremental conservatism. Go figure.
It’s a Whole New World
It’s worth noting several points here:
- The W3C failed dramatically at maintaining HTML (which is kind of scary when you think about it).
- Web standards are incredibly haphazard. There was—and is—no unifying vision of “HTML5.” It was just a bunch of separate specifications bundled up and given the name “HTML5,” and those specifications came about only as a reaction to the W3C’s failures.
- Big, bold ideas such as the march to XML for the Web—which had many people excited a decade ago—can fade to nothing. We should learn from this and retain some skepticism toward big, bold ideas, including some of the changes in HTML5.
- The balance of power now rests with the browser vendors.
In truth, the balance of power has always rested with the browser vendors. If they don’t implement something, by definition it’s a nonstarter. Hickson says this (www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/):
The reality is that the browser vendors have the ultimate veto on everything in the spec, since if they don’t implement it, the spec is nothing but a work of fiction. So they have a lot of influence—I don’t want to be writing fiction, I want to be writing a spec that documents the actual behavior of browsers.
Whether that’s too much, I don’t know. Does gravity have too much influence on objects on earth? It’s just the way it is.
Nevertheless, the fact an independent standards body—our independent standards body—failed miserably is more than a little concerning.
To HTML5 and Beyond!
To cut a long story short, the WHATWG kept working on its own vision of evolving HTML—the only vision of evolving HTML. And in 2006 Tim Berners-Lee, father of the World Wide Web and director of the W3C (read more about him here: http://en.wikipedia.org/wiki/Tim_Berners-Lee), sucked it up and announced the W3C would work with the WHATWG, saying this (http://dig.csail.mit.edu/breadcrumbs/node/166):
The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work.
Berners-Lee left the door open to switching to XML by saying “all at once.” But in reality it looks very much like “The attempt to get the world to switch to XML . . . didn’t work.”
And that’s fine. We need big ideas and bold directions to try and work toward, and if they don’t work out, so be it. Sometimes good ideas just don’t happen.
With the WHATWG having so much momentum (and the backing of the browser vendors), the W3C had no choice but to work with the WHATWG on HTML5. In 2007 the W3C formed a group that worked with the WHATWG on developing HTML5. And in January 2008 the W3C released its first HTML5 Working Draft (www.w3.org/TR/2008/WD-html5-20080122/), adopting the work the WHATWG had been doing for several years.
HTML5 Is the New Black or Hotness or Something
By the late ’00s web technologies were exciting again, and after years of stagnation and dead ends we finally reached a point where the bowels of innovation were loosened. (That’s a horrible image—sorry.)
Starting in the early ’10s and continuing to the present, things are looking even better. In fact, there continues to be a veritable Cambrian explosion of web technology taking place. Google, Mozilla, Apple, and Microsoft are competing to make the best standards-compliant browser (with new versions coming thick and fast—Google Chrome releases so quickly it’s not even worth tracking its release schedule). There’s a whole bunch of new and interesting technology around. And web developers, designers, software companies, and app developers are all interested in the new and shiny tech in and around HTML5.
To think browser makers—including Microsoft—are now trying to outcompete and even out-market each other with their web standards support is pretty incredible. It wasn’t that long ago (late ’90s) that we faced the threat of them all going their own nonstandard ways. Hats off to all involved.
Is HTML5 Hype, Substance, or Both?
But back to the HTML5 specification. Two questions:
- What exactly is HTML5?
- Who’s in charge now that there’s a (decidedly uneasy) working relationship between the establishment (the W3C) and the rebels (the WHATWG)?
Let’s deal with what HTML5 is first. There’s:
- HTML5, the all-encompassing marketing buzzword
- HTML5, the bit that’s actually about HyperText Markup
- HTML5, the new functionality available through JavaScript for web applications
- HTML5, the behind-the-scenes stuff that’s really important and documents a whole lot of stuff browsers actually do (but you’re probably not interested in)
All this comes from a technical specification that runs for hundreds of pages.
For us web designers, HTML5 is currently a confusing mix of hype and substance, which we’ll try to sort through in the coming chapters.
In many ways, HTML5 is, to put it bluntly, a mess. But it’s the most ordered mess we’ve had in a long time. (For instance, a big part of HTML5 is written for browser vendors to ensure implementations are consistent and we can trust all browsers to do the same thing. And that’s never been done before.)
Perhaps the biggest problem is everyone thinking that if HTML5 is cool, then all of it (at least according to the web design community) must be great, and we should adopt it post-haste without too much critical thought. And that’s something I’m keen to dispel in the rest of the book because while HTML5 certainly has some great ideas, it’s not as great as you may think, and without a lot of critical thought we’re likely to wind up in a great deal of trouble.
For a long time, both the WHATWG and W3C versions of the HTML5 spec (the differences between the two are minor) were edited by one person: Ian Hickson. In September 2012 the W3C introduced a larger team of editors to oversee what went into the actual HTML5 spec and what was divided into other specs, but it still largely pulls from the WHATWG specification, which is authored solely by Ian Hickson.
HTML is essentially in the hands of one man.
The W3C’s working groups tried building consensus and got absolutely nowhere with HTML. It was closed but democratic. The WHATWG, on the other hand, has an open process but with an editor-has-the-final-say approach.
And that editor is Ian “Hixie” Hickson.
Hickson helped start the WHATWG when working for Opera and now works full-time for Google developing the HTML5 spec. Currently, he is the HTML5 (and now just “HTML”) editor for life. Theoretically, the browser makers can veto him or kick him out at any time, but that seems highly unlikely. This has not gone unnoticed in the community and is (rightly, in my opinion) a cause of some concern.
It’s a classic “glass half-full/glass half-empty” situation. If Hickson flat out refuses an idea (which is known to happen), then having a single person in charge may seem like utter madness. But for those who saw the W3C’s democratic processes get nowhere with XHTML 2.0, having someone who can take the reins, push things along, and actually make decisions would seem wonderful.
Of course, this invariably polarizes people.
Here’s John Gruber of Daring Fireball fame (http://daringfireball.net/linked/2009/07/01/hickson-codecs):
Let it be said that Ian Hickson is the Solomon of web standards; his summary of the situation is mind-bogglingly even-handed and fair-minded.
And here’s Kyle Weems, creator of the CSSquirrel comic, who has been following HTML5’s development for several years (http://twitter.com/#!/cssquirrel/status/58559284224589824):
Also . . . why oh why is @hixie still the editor for any world-altering spec like HTML anymore? Ego doesn’t even begin to describe his antics
As you can see, Hickson has his fans and his detractors.
I imagine editing a spec the size of HTML5 for as long as he has, with all the controversy that surrounds it, would be a pretty thankless task. But Hickson seems to go about it in a cheerful, dispassionate way.
If there’s one overarching theme here, it’s this: pragmatism rules.
The W3C had the “pure” spec of XHTML 2.0 and failed—it wasn’t pragmatic. It also had its rules, membership, and democratic processes but was mired in politics and failed (with HTML at least)—it wasn’t pragmatic.
The WHATWG put an editor in charge, and while this approach terrified and/or infuriated some people (including me from time to time, as you’ll soon see), it was pragmatic (as was its approach to the spec). It got things moving (and, more importantly, shipping). And as long as it remains pragmatic, it’s probably how the WHATWG will stay.
XHTML 2.0 Is Dead and Everyone Is Happy
So, what happened to XHTML 2.0? It was pronounced dead after being taken off life support in 2009 (www.w3.org/2009/06/xhtml-faq.html). I hear the death of XHTML 2.0 will soon be fictionalized in an upcoming episode of Law & Order: Web Standards Unit.
And what about XHTML 1.0 and its various flavors? Considering it’s essentially just HTML, it will keep working pretty much forever. (There’s actually a continuing XML serialization of HTML5 called XHTML5, but the chance of you actually needing to use it is practically zero.)
HTML5 . . . er . . . HTML, wait . . . HTML.next?
To show how things have come full circle with the HTML spec, the WHATWG declared in January 2011 that its HTML5 spec would be a “living standard” and renamed it to just HTML. (See the announcement at http://blog.whatwg.org/html-is-the-new-html5 and the rationale at http://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F.)
And what of the future of HTML? The WHATWG insists it—and particularly Hickson—will maintain the HTML spec as a “living standard” indefinitely, while the W3C is sticking with the snapshot process and is simultaneously wrapping up “HTML5” while working on the next version, previously called “HTML.next” and now titled “HTML5.1.” (See some of the ideas here: http://www.w3.org/wiki/HTML/next.)
(A W3C member gave a personal presentation that captures the differing approaches to the future of HTML quite nicely: www.w3.org/2010/11/TPAC/HTMLnext-perspectives.pdf.)
Will the W3C come up with another pie-in-the-sky path to nowhere (echoing 1998’s “Shaping the Future of HTML” workshop; www.w3.org/MarkUp/future/)? Will the W3C try to work with the WHATWG or fork HTML5 and do their own thing? Who knows. Some have been asking if the W3C should even exist.
Should We Just Kill Off the W3C Altogether or Embrace It?
In September 2011, a debate broke out about the purpose of the W3C, and three broad views emerged: reform, destroy, and embrace.
Before we get to those three views, let’s consider why debate about the W3C is still continuing just as it seems to have its house in order, having adopted the WHATWG’s successful HTML5 specification.
In short, it’s because the world kept turning. The WHATWG began its work on what became HTML5 in the mid-2000s, and the details of HTML5 (and related specifications) are still being nutted out in the 2010s. Mobile is exploding, “apps” are taking us back to the platform-specific software world of the ’90s, and standards development is still slow, even in this new wow-stuff-is-actually-happening environment we now enjoy.
Can the Web keep up in the face of resurgent, platform-specific app development? Has the W3C outlived its usefulness, or is it now finally back on track after years in the wilderness? Here are three perspectives, all from September 2011.
In “Things the W3C Should Stop Doing” (http://infrequently.org/2011/09/things-the-w3c-should-stop-doing/), Alex Russell, who works for Google on Chrome, argues the W3C needs to drop all its XML and enterprise stuff and refocus solely on the Web. Essentially, drastic reform can save the W3C from irrelevance.
The time has come for the W3C to grab the mantle of the web, shake off its self-doubt, and move to a place where doing good isn’t measured by numbers of specs and activities, but by impact for web developers.
In “Web Technologies Need an Owner” (http://joehewitt.com/2011/09/22/web-technologies-need-an-owner), Joe Hewitt, who worked on early versions of Firefox, created Firebug, and was responsible for the iPhone Facebook app, argues the Web is just another platform but without anyone taking responsibility for it (unlike Windows, Android, and iOS).
Let’s face facts: the Web will never be the dominant platform. There will forever be other important platforms competing for users’ time. To thrive, HTML and company need what those other platforms have: a single source repository and a good owner to drive it. A standards body is not suited to perform this role. Browser vendors are innovating in some areas, but they are stalled by the standards process in so many areas that is impossible to create a platform with a coherent, unified vision the way Apple has with Cocoa or the way Python has with Guido.
Therefore, we should destroy it, as Hewitt tweeted (https://twitter.com/joehewitt/status/116292923288592384):
[D]issolve the W3C, and run the web like an open source project. No more specs, just commits. Does Linux need a standards body?
Finally, in “The Web is a different problem” (www.webdirections.org/blog/theweb-is-a-different-problem/), John Allsopp, longstanding web evangelist, writer, and speaker, argues that while standards development certainly stalled in the ’00s, we’ve seen an “explosion of innovation at the browser level” in the last few years, particularly with CSS3 and more modular specs, and are we really now going to throw the baby out with the bathwater?
So, to put it bluntly, I think the problem is overstated. We seem to have arrived at an approach that both enables the exploration and implementation of novel features in browsers, which are also widely adopted across browsers. [ . . . ]
[But] the web is a different problem. It makes little if any sense to compare innovation of the web ecosystem with that of iOS, Android or other platforms. The web faces challenges far far greater (and has goals far more important). [ . . . ]
So, rather than generally criticising the W3C, or going so far as calling for its dissolution, we should focus on how well in many ways it has done an almost impossible task—getting companies which are fierce commercial rivals to sit down, work together and agree on core technologies they will each, and all, implement, even while at the same time, these same competitors are involved in significant legal conflicts with one another.
Whatever we may wish for, sheer inertia is likely to see the W3C maintain its role as the home of web standards development in the coming years (for better or worse), especially now that it has brought the WHATWG and HTML5 inside the W3C tent.
How Does New Stuff Get Added to HTML5 Now?
How will HTML5 evolve from here on out? How will the WHATWG implement new HTML features in its “living standard”? The WHATWG says new HTML features should first appear in browsers (experimentally at least) and then be codified into the spec, assuming there’s a reasonable use case for them and the editor approves. (See the WHATWG FAQ for more: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F.)
This means the HTML spec will capture features as they emerge, rather than dictate new features from scratch—a somewhat odd stance given the amount of innovation the WHATWG did in the HTML5 spec before any browser implementation.
How long will the WHATWG/W3C relationship last? Your guess is as good as mine. Hickson has been openly hostile to the W3C’s process at times (http://lists.w3.org/Archives/Public/www-archive/2012Jan/0032.html), and his decisions and refusals continue to be a source of considerable friction on the W3C mailing lists.
At the end of the day, either party can dream up all the specs they like. What really matters is what the browser vendors choose to implement. As far as HTML is concerned, the WHATWG’s extremely close relationship with the browser vendors means it’ll probably be calling the shots for the foreseeable future.
In September 2012 the W3C introduced its own team of editors, deposing Hixie as the king supreme of HTML5, at least in theory. The W3C explained the decision as one made at Hickson’s request in a blog post in April 2012 (http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html):
We have reached a point in the HTML WG where the W3C process and community expects to finalize the HTML 5 Recommendation-track specifications. For the last several years, Ian Hickson has been the editor of the HTML 5 spec. At the same time, we all recognize that work will begin on ‘what will come after HTML 5’. As Ian is already working on proposals for this work, he has asked the chairs if someone else could volunteer to take the HTML 5 spec to REC. Today, we are announcing the following changes:
* W3C is starting a search for editors to begin the REC level work on HTML5 and HTML Canvas 2D Context. We anticipate this search will take 30 days.
* Anyone is welcome to contribute proposals that could be used as input for future products of the HTML WG, either based on the work of Community Groups, or based on proposal drafts created in an HTML WG Task Force or the HTML WG itself.
* Ian will continue editing the WHATWG HTML specification, which we anticipate will be one such proposal.
* Editors of Recommendation-Level specifications and authors of HTML.next proposals are encouraged to work together to avoid introducing contradictions, but are free to make their own changes directly.
* W3C has started the process of extending the W3C HTML WG charter to jump start the work on HTML.Next in parallel to completing the current Recommendation track work. Once the HTML WG is re-chartered then the W3C will review proposals for HTML.Next work, and seek additional editors or co-editors for HTML.Next work.
* As W3C proceeds with its work on follow-ons to HTML 5, W3C and the WHATWG plan to continue their partnership in developing the right features for the future web.
In July, the W3C’s new editorial team was announced, and now in 2013 it’s been expanded (with Ian Hickson still listed as a participating editor).
So, by the W3C’s explanation, HTML5 needs to be standardized and set in stone. WHATWG is working on a living standard that will never be finished, so the W3C needed to break away, take a snap shot, and lock down HTML5. HTML development will continue as “HTML.next” (referred to as HTML5.1 by late 2013) and continue drawing inspiration and ideas from the WHATWG specification.
In September 2013 the W3C gave itself a new charter for the HTML5 spec that lasts through July 2015, specifying its license for distributing the HTML5 spec and redeclaring its intention to publish a formal and finished HTML5.0 specification in 2014 (www.w3.org/blog/news/archives/3253). None of this is mirrored by the WHATWG, though Hickson’s involvement in both is intended to keep the two groups from diverging too far.
In the year since the W3C and WHATWG diverged, little has changed in the W3C spec. The W3C has focused on breaking the single, large HTML5 spec proposed by the WHATWG into several smaller specs. Isolated differences have emerged, but both the W3C and WHATWG, groups that are publishing specifications about how HTML5 should work, frequently affirm that nothing matters until the browsers implement a feature. Let me say that again: in 2013, the W3C and WHATWG are again working on different specifications, and both agree that only the browser makers’ decisions really matter. See the following two URLs for more info:
http://html5doctor.com/interview-with-robin-berjon-html5-editor/
http://dev.w3.org/html5/decision-policy/html5-stabilization-plan.html
So, after all that, we’re back in a familiar place. The W3C has a group of editors working on a spec, the WHATWG has an editor working on their spec, and the major browser companies are involved in both and implement whatever they think works best. There’s more cooperation and commitment on all fronts this time, but it still feels eerily familiar. We’re back to HTML.
That wraps up our somewhat sensationalized (and highly condensed) history of HTML5. Or HTML. Or . . . you get the idea.
TL;DR
In summary, the W3C tried to kill HTML and took us on a decade-long journey to nowhere; some people from browser vendors formed a group interested in web apps and evolving HTML’s forms; they worked outside the W3C on what became HTML5; the W3C realized they were screwed and agreed to use their work; browser vendors are implementing it (or their existing implementations of certain features have been standardized); web standards have become a Microsoft marketing buzzword; hell has not frozen over.
What We’ll Be Focusing On
HTML5 is a massive specification, filled with mind-numbing detail for browser vendors.
But that detail is actually the best thing about it. Removing the implementation ambiguities has led to more predictable behavior, which is good news for designers and developers alike. (Before that, browser vendors were looking over each other’s shoulders to see how parts of the spec were interpreted.)
It’s not sexy work but rather years of careful documentation and clarification by the WHATWG that we can all be grateful for.
The other parts of HTML5 very much reflect its origins as Web Applications 1.0 and Web Forms 2.0. We’ll touch on the web app stuff in Chapter 12 and look at the web forms in Chapter 8.
As designers, the biggest point of interest are the changes and additions to the actual markup side of HTML. And that’s what we’ll focus on: semantics, forms, graphics, and audio/video.
We’ll also touch on the new features for web apps in HTML5, which we’ll hopefully see in our content management systems sooner rather than later.
Most importantly, though, we’ll be looking at the ideas in markup and the practical—sometimes critical—dos and don’ts of HTML5 along the way.
Let’s jump in and look at how we start a document in HTML5.