April 20, 2011
The web development and design world has been abuzz about HTML5, kind of like how “Web 2.0” was all the rage waaaay back in 2007. (Epochs don’t last very long on the web, do they?) But unlike “Web 2.0,” HTML5 clearly represents a tangible and unambiguous new set of tools to create websites. It is the long-awaited fifth incarnation of HTML, the fourth one having been finished for over a decade. Like with the previous numbered versions of our favorite markup language, coming with HTML5 are tasty new tags, like <header> and <article>. But along with new tags comes a new way for HTML to interact with the webpage.
HTML5 will not be done until 2014 but you can use most of these new tools now. Wait! Stop reaching for that paper bag. There is no need to panic. If you indeed start using HTML5 now you don’t have to go back and recode all of your old sites. HTML5 doesn’t replace all of the old markup, it can just improve it. So don’t worry about going back through the history of your old web pages and changing them.
Speaking of history, HTML5’s is kind of long and complicated. Grab a sandwich and read the Wikipedia article on it if you want the long version. I’ll try and give you the cliff notes version: in the late 1990’s, development of HTML stopped in favor of a hybrid with XML called XHTML. But web developers did not like how draconian the error handling was with the XHTML doctype so they continued to use the old standard HTML doctype, or a transitional one, to get the XHTML coding police off their backs. A group of developers splintered off from the W3C, known as the WHAT Working Group, wanting to develop HTML more. The result was HTML5. In 2006, the folks at WHAT were welcomed back into the W3C fold and development of XHTML was shut down in 2009.
The new doctype for HTML5 documents, as opposed to the sometimes long and convoluted doctypes you might have grown accustomed to the last ten years, is simply this: <!DOCTYPEhtml>
Brilliant, eh? The KISS principle comes to HTML doctypes! Makes you want to rock and roll all night and party every day doesn’t it?
So what are these new tags and features? First, to be perfectly honest with you, a lot of them have more to do with semantics than actual, visible functionality. Some new tags will probably always be that way; others will surely pick up some (or more) interactive functionality as HTML5 develops further. This is the confusing part for most HTML5 newbies.
Let’s take the <header> tag for example. As you might be able to guess, you want to put header content between the new <header> tags. That’s pretty much it. No, it doesn’t automatically put that content at the top of the page. You can put it anywhere you like, actually, and how you style it is still totally up to you and your CSS. “Well then, why don’t you just use a div tag with a class ‘header?’ What’s the big deal?” a Debbie-Downer-Developer might ask. And the typical response to that question from an HTML5 early-adopter is “Um… well, you see… um… because it’s HTML5!” Here’s the thing: tags like <header> and <footer> make your markup more semantical. It can not only make your code prettier and make more sense, but it can simplify CSS-coding as well, since you now have new tags to put universal attributes on, as opposed to applying a class or ID “header” over and over again to DIV elements. Search Engine Optimization (SEO) also comes into play (or, will later when search engines get up to speed) as bots typically love simpler and more elegant code to crawl through; <header>
easily tells them where header content is supposed to be and, <nav> more importantly, tells them where the navigation is, which bots will happily use to crawl through the rest of the site. Delineation of different types of content will also be quite useful (depending on how you use that delineation).
For example, with the <article> tag: it’s intended for forum posts or news articles, or any content that makes sense on its own and can be independently distributed and/or syndicated. This bodes well for more diverse ways of content consumption. More great examples of this are the <figure> and <figcaption>
tags, where in the markup you may, better than ever before, specify content like photos or charts or graphs and accompanying captions.
Another good example is the <aside> tag. Its intention is to contain related content that can be left aside if need be, as for displays with limited real estate, as in the mobile environment. In fact, HTML5 was developed with the emerging mobile web very much in mind. This is especially true of the HTML5 elements that do have an interactive aspect to them (or, they will, once they’re more supported). But native mobile apps can be coded in HTML5, and at the same time HTML5, ironically, can be used to avoid making native apps, as it has lots of potential and uses in the mobile web-apps.
A primary example of an element great for mobile is the once highly-anticipated, now much-maligned <video> tag. It was intended to be a simpler way of displaying and interacting with video content on a webpage without the need of Flash. This was great news for people with mobile phones that didn’t support Flash. However with the format, licensing, and patenting wars going on with it excitement over it has gone sour (this is long, convoluted, and worthy of its own blog post). The <audio> tag had similar aims as the <video> tag and unfortunately it’s having some of the same problems.
We’re not just waiting for developers to do cool stuff with HTML5. We’re also waiting for the browsers to do so too. Google’s Chrome browser has already implemented default styles for tags like <meter> and <progress> - a nice green progress bar is displayed (an animated one for the latter). The <details> tag is supposed to create expandable/collapsible modules, but no browsers yet - not even Chrome - seem to be supporting it. But, once all of the browsers support those tags and others like it, coding a website with neat-o interactive elements will prove to be much easier for the average front-end developer who might not know advanced AJAX or JQuery – and even if they do, much time should be saved. This is because functionality will come with the tag and won’t need to be coded, and this is because of that built-in relationship HTML5 has with the DOM that I’d mentioned earlier in this post.
So for now, let’s start using the semantic HTML5 tags – it won’t hurt anything if you do – and I guess we’ll just have to wait for expandable/collapsible content that takes a little bit longer to code than it does to type the word “details.”
comments powered by