Get familiar with HTML5!
Most of the web standards curriculum is based on the last stable version of HTML — HTML 4.01. The HTML 4.01 spec was completed in 1999, over 10 years ago as of the time of this writing! But unless you've been hiding under a rock for the last year or so, you'll be well aware that there is a new version of HTML in development — HTML5!
So why have we been teaching you HTML 4.01 in spite of this? In this article we'll answer this question, and many more. We'll give you the essential background you need to know on why HTML5 came about, and where it is up to now. We'll advise you on how it can fit into your learning right now, even if you are a novice web designer or developer, and we will look at some of the main features of HTML5, so you can see what it adds to the already powerful HTML language.
When HTML 4 was nearing completion, the W3C decided (in a workshop run in 1998) that in terms of markup languages, the future of the Web was XML and XHTML, not HTML (comparison of XHTML and HTML). So the W3C drew a line under HTML 4.01 and instead concentrated on the XHTML 1.0 spec, finished in early 2000. XHTML 1.0 is just the same as HTML 4.01, except that it uses the markup syntax rules of XML. XHTML 2.0 soon followed, which added a whole bunch of new powerful features and an XML-only mime-type, and aimed to be the next big thing on the Web.
The trouble with XHTML 2.0 is that it wasn't backwards compatible with the markup already on the Web - the elements worked differently, the XHTML mimetype (
application/xhtml+xml) did not work at all on IE, which still has the majority browser marketshare as of the time of writing, the developer tools available weren't ready for working with XML, and it didn't really reflect what web developers were REALLY doing out there in the wild wild web.
In 2004, a group of like minded developers and implementers (including representatives from Opera, Mozilla and slightly later, Apple) got together and formed a breakaway spec group called the WHATWG, with the aim of writing a better HTML markup spec that could handle authoring the new breed of web applications, without - crucially - breaking backwards compatibility.
The result was the Web Applications 1.0 specification, which documented existing interoperable browser behaviours and features, as well as new features for the Web stack such as APIs and new DOM parsing rules. After many discussions between W3C Members, on March 7 2007 the work on HTML was restarted with a new HTML Working Group in an open participation process. In the first few days, hundreds of participants joined to continue to work on the next version of HTML. One of the first decisions of the HTML WG was to adopt the Web Applications 1.0 spec and call it HTML5.
HTML5 is a really good thing for web developers and designers, because it:
- Is better suited to writing dynamic applications than previous HTML versions (HTML was originally designed for creating static documents).
- Has a clearly defined parsing algorithm so that all browsers implementing HTML5 will create the same DOM from the same markup, regardless of validity. This is a massive win for interoperability.
What does HTML5 mean to me?
To start with, let's answer that question you've had circling round your head since you started reading this article — why did we teach you most of the web standards curriculum using HTML 4.01, if HTML5 is on the horizon? First of all, when the WSC was first published in 2008, HTML5 was a lot more in flux than it is now, and we didn't want to teach you something that would likely be changed at a later date.
Second, and more importantly, HTML5 is backwards compatible — in practical terms, this means that all the stuff inside HTML 4.01 is also in HTML5. So by learning HTML 4.01, you are also learning a large chunk of HTML5. This article, and the others inside this section, aim to fill in your knowledge gaps by teaching you the extra bits that HTML5 layers on top of HTML 4.01, for example the extra semantic elements, and the new APIs that allow you to control video playback and draw pictures on a canvas. I'll give you loads of references to more information on such features at the end of the article.
Some parts of HTML5 are implemented in a stable enough fashion across browsers to be used safely even on a production site (as always, you will have to make a judgement call depending on your site's target audience and features). Plus if a feature is not supported in certain browsers, you can work around this — our articles will show you how, at appropriate points.
To give you a short concluding answer, HTML5 is the future of the Web, and a large part of your future as a web designer or developer. I'd recommend that you start learning HTML5 as soon as you are ready — many of the new features will make your existing work a lot easier, and it will future proof your knowledge. If you are a student at college or university and your teacher doesn't know about HTML5 yet, or is unwilling to cover it in your course, show them this article.
HTML5 contains many new features to make HTML much more powerful and suitable for building Web applications. In the list below I've summarized the main ones you really should know about.
Some of the features listed below are NOT actually part of the HTML5 spec itself, but are defined in closely related specs, therefore they are still valid parts of the new movement towards modern web applications, and useful for you to know about.
New semantic elements: As you will already know, semantics are very important in HTML — we should always use the appropriate element for the job. In HTML 4.01 we have a problem — yes, there are many elements for defining specific means such as tables, lists, headings, etc., but there are also many common web page features that have no element to define them. Think of site headers, footers, navigation menus, etc. — up until now we have defined these using
<div id="xxx"></div>, which we can understand, but machines can't, plus different web developers will use different IDs and classes. Fortunately, HTML5 comes with new semantic elements such as
<article>. You can learn about these in our article New structural elements in HTML5.
New form features: HTML 4.01 already allows us to create usable, accessible web forms, but some common form features are more fiddly than they should be, and require hacking to implement. HTML5 provides a standardized, simple way to implement features such as date pickers, sliders and client-side validation. HTML5 forms are covered in detail in the article New form features in HTML5.
Native video and audio: For years, video and audio on the Web has been done using Flash, generally speaking. In fact, the reason Flash became so popular around the dawn of the 21st century is because open standards failed to provide a cross-browser compatible mechanism for implementing such things, with different browsers implementing different competing ways of doing the same thing (eg
<embed>) and thereby making the whole process really complicated. Flash provided a high quality, easy way of making video work cross-browser.
<audio>elements for implementing native video and audio players really easily with nothing but open standards, and it also includes an API to allow you to easily implement custom player controls. There are many articles on dev.opera.com covering HTML5 video and audio, but the best place to start is Bruce Lawson and Pat Lauke's inaugural Introduction to HTML5 video article. Also worth checking out is the More accessible HTML5 video player.
Canvas drawing API: The
Web Sockets: This API (defined in the Web Sockets spec, separate from the HTML5 spec) allows you to open a continuous connection between a sever and a client on a specific port and send data in both directions until the port is closed. This improves the efficiency of web applications a great deal, as data can be continuously and accurately exchanged between client and server without constant page reloads, and without constantly having to poll the server to see if updates are available. Introducing Web Sockets will start you off nicely.
Offline web applications: HTML5 provides a number of features to allow web applications to run offline. Application Caches allow you to save a copy of all the assets and other files needed to run web applications locally, and Web SQL databases allow you to save a local copy of a web application's data. Together, these allow you to continue using an application when it goes offline, and then synchronize changes with the master version on the server when the network is available again.
Web Storage: Cookies allow us some degree of local data storage, but their use is fairly limited. HTML5 Web Storage allows us to store a lot more data, and do a lot more with it. Read Web Storage: easier, more powerful client-side data storage by Shwetank Dixit for more information.
Web workers: A common problem encountered by web applications is that their performance suffers when a lot of data processing is required, due to the fact that everything happens in a single thread/process (only one load of processing can happen at once). Web Workers mitigates this problem by allowing us to create background processes to take care of some of the number crunching, allowing the main process to get on with other things. To read more about Web Workers, go to Daniel Davis' Web Workers rise up!.
Geolocation: The Geolocation spec (again, not a part of the HTML5 spec) defines an API that allows a web application to easily access any location data that has been made available, for example by a device's GPS capabilities. This allows you to add all kinds of useful location-aware features to your applications, for example highlighting content that is more relevant to your location. For a basic introduction, read How to use the W3C Geolocation API.
Note: CSS3 is DEFINITELY NOT part of HTML5, and never will be. Don't let your marketing department tell you otherwise.
And so finishes your brief introduction to HTML5. I hope you found this useful, and that you will continue reading the other articles about HTML5 referenced above.
This article is licensed under a Creative Commons Attribution 3.0 Unported license.