HTML is arguably the foundation of everything that makes the World Wide Web what it is today. It is simple enough to write that just about anyone can pick it up – not too much unlike learning to play the guitar: If you have the ability to learn three chords and grimace musically, you might be able to join a rock band. Same with HTML: Learn a few tags, and you too can be an Internet sensation.
When the curators of web technologies–the W3C—decided we’d all be better off moving towards XML via the XHTML specifications, I was all for it. I dutifully embraced the rigors of XML nesting rules and self-closing tags, and learned how to properly attach semantic markup to content and style it using cascading style sheets. And that was fine, until…
Well, the fact is that XHTML broke one of the foundations of what made HTML itself so great; it broke the simplicity. XHTML was supposed to act like XML, meaning XHTML was supposed to be interpreted strictly, and invalid markup should cause the interpreter to fail.
There were other problems too. Web servers and web browsers never fully caught on to the potential, let some things slide here and there, and the XHTML 2.0 working group was looking to be one of the most dysfunctional standards bodies the web had ever seen. XHTML wasn’t working out for the long term.
Then HTML5 came along.
It’s a shame to throw the baby out with the bathwater, right? HTML got us along this far with the World Wide Web, so why discard it now? One guiding principle of HTML5 is this: “Let’s hang on to HTML and promote what makes HTML so successful.” Simplicity is what made HTML successful in the first place. So let’s make things simple again in HTML5, and find out what would make it work even better.
It took me quite a while to reconcile my biases against HTML5. After years of evangelizing XML-style rules of XHTML, giving users the option to do unholy HTML practices such as not adding the slash-anglebracket closing of standalone tags—or even worse—uppercase HTML elements, was perceived by web standardistas for years as crimes against humanity. But after combing through the latest state of the spec, researching the benefits, and observing the consensus that has formed around it in the web community at large, not to mention seeing a few well written books out there composed by some highly regarded experts, I am finally at peace with the HTML5 movement and ready to endorse its use across the board.
Now I know what some of you are thinking: “But isn’t this is just a specification under development? Won’t this take years before it’s ready for me to use in my daily work?”
The answer to this is mostly no, you don’t have to wait—you can start using aspects of HTML5 today. While there are some dreamy parts of the spec that we’d like to see someday, for the most part things will work in modern browsers or can be modified to work with slightly older browsers like IE7. But much of this stuff works today. More importantly, this stuff will work across the majority of modern shipping browsers in the very near future—specifically when IE9 ships. And it does work today in the majority of mobile devices out there with usable web browsers, including iPhone and iPad, Android devices, and new BlackBerry platform.
And you might as well start learning now. XHTML is officially a dead-end branch by itself, though parts of it live on through the activities of the HTML5 specification (and in particular, the XHTML5 portion of the HTML5 effort.) While the HTML 4 and XHTML specifications are still quite valid and will continue to work in new browsers, the future of the web is HTML5.
OH: HTML5 is the new Web 2.0
Sigh. This is the new buzzword, folks. At least, that’s how it is getting used lately. This became painfully apparent when today I noticed a Wired article that discussed how a lawsuit is being filed against an advertising company because they are circumventing privacy law by bypassing using cookies to track users and are instead using the HTML5 offline database API. Brilliant idea—terrible consequences. You can flush cookies from your browser, but there’s no way to flush your offline databases in the API unless the app you’re using specifically allows for it. Ha! Case law for HTML5 means it’s time has come.
But more to the point, HTML5 is being used as a blanket term for all those shiny, trendy new web techniques we see people using today in modern web development. Instead of asking “how Web 2.0-ey is that thing,” people now evaluate new web trendiness based on how HTML5-ish their widgets are. Nowhere is this more apparent than in the current web browser landscape, where browser vendors tout their support of HTML5 instead of touting whatever proprietary extensions they may have packed on. Despite the shameful abuse of terminology, overall this trend towards better standards support is a Good Thing™ – web standards have caught on and have gone mainstream.
HTML5 is here to stay
As I mentioned earlier, HTML5 is the successor to all other flavors of markup – HTML 4, XHTML1, and the rest of it. All branches have now merged into one specification. If you like XHTML, you can continue to use XML-style syntax rules in HTML5. But it’s not necessary, and is arguably a waste of bytes – The HTML5 DOM allows for HTML4-style unquoted attributes and standalone tags that aren’t self-closing. All modern browsers will parse your code just fine. Unless you need the extensibility of real XHTML, use the regular HTML variant.
All modern browsers will support HTML5. This includes the last holdout, Internet Explorer, which as of version 9 (currently in beta as of this writing) will have the very solid beginnings of HTML5 implementation. At some point in the near future, all browsers in the hands of your web users will be capable of handling most or all of what is currently in the HTML5 specification. We will probably be in the 50% mark for HTML5-positive public web users somewhere in the first quarter of 2011, and if mobile web trends continue down the current path then I’d expect that to be close to 75% by the beginning of 2012. Wild ass guess, but what the heck.
The HTML5 spec will be the last version of HTML to be published. But it will not be a static fixture set in marble for us all to behold ad nauseum. No, instead of the past models where things were published and left for dead by the W3C, HTML5 intends to be a living document – an expression of the working capabilities of the modern web landscape, rather than some ivory tower ideal that we should all strive to achieve. At least, that’s what we hear (and what some of us hope…)
With all that said, let’s put to rest the question of whether or not we should be pursuing HTML5 as a skill or a development strategy at this time. The answer is yes – you should start doing this right now.
The HTML5 philosophy
For a moment now, let me attempt to define the philosophy of what HTML5 is:
HTML5 specifies what is practical in modern web browsers. It covers semantic structure, the document object model, and certain features that really do blur the lines between markup and functionality. It is more a web application framework than just a simple markup language, and in fact I think of the markup portion of HTML5 now as a sort of subset of the greater HTML5 umbrella.
Much of the HTML5 specification is defining in semantic or in operational terms what is already possible in web browsers and in wide enough use to justify itself.
It will have you scratching your head at times if you’re well versed in HTML 4 or XHTML 1.0, because some things will appear completely foreign to you. Just remember this: HTML5 is not just a markup language. It is an application framework. It is a document object model. It is a set of APIs. It is the new Web 2.0.
What specifically is HTML5 then?
OK, ok… I’ll be specific. Here are some of the primary features of HTML5-the-specification:
- A new markup specification: Most of the markup from HTML4 exists, with only a few elements deprecated. Some elements which were deprecated in XHTML are now redefined in HTML5 as being perfectly valid, including <b> and <i>. Other elements have been created to simplify semantic patterns that have been observed in modern web development, such as <article> and <footer>. Yet more new elements appear to extend the functionality of web interfaces, such as <canvas> and <video>. HTML5 replaces all prior versions of HTML and XHTML from the W3C’s perspective.
- New APIs: Some of these new APIs include the aforementioned <canvas> element, offline data storage, editable content, and semantic structures such as microdata. This alone is a big stretch over what prior HTML specifications included, but it is important to consider these as part of how the browser, markup, and DOM should interact.
- New rules: Markup doesn’t need to be strictly upper- or lower-cased. It can even be mixed case. (But please, stick with lower case – I urge you.) Markup may be served as text/html. You can go ahead and insert SVG and MathML in your markup served as text/html – it’s OK!
The working draft of the HTML5 spec is available on the W3C site, and I do think it is valuable to reference it whenever you have a question about the intent of a certain element or API. I’ll try to link to those points as we get deeper into these features in upcoming posts, so stay tuned!
What is HTML5 not?
- HTML5 is not CSS3, so don’t go there. CSS3 does work very well with the modern and emerging browsers and with HTML5, but it’s a different spec. Every time CSS3 gets lumped together with HTML5 as a blanket term, an angel cries.
- HTML5 is not the answer to all your problems. It is pretty cool – don’t get me wrong – and it corrects the vast majority of mistakes created by HTML 4 and XHTML. But it’s still a work in progress and has it’s own quirks and areas where we may need to tread carefully. We’ll look at some of these issues as we go along.
What do we do now, Ren?
In my next post, we will look at the new semantic structures of HTML5 and how to start using HTML5’s new markup rules today. Thank you and happy HTML5-ing!