Stop and think for a moment about how long you've been a developer. For some of you, that journey started recently. For others, it has been years. However long it's been, do you realize that less than a decade ago, the .NET revolution had not officially started? Classic ASP was the primary way we developed for the web, and HTML was at version—wait a minute—is still at version 4.01!
A Brief History of HTML5
Before we discuss what HTML5 has to offer, we should note that attempts have been made to change HTML. Note the word is change, not upgrade or revise. But what does that mean? Why is it important to consider the failed attempts to change HTML? So that you can appreciate why HTML5 is worth investigating and why it is here to stay. For these reasons, let's take a brief journey down memory lane and consider the series of events that led to where we are today. Then we'll discuss where we'll be tomorrow.
You probably already know who Tim Berners-Lee is and that HTML came into existence as far back as 1989. You also probably know that the Internet took off in the 1990s, and so on. So instead of strolling through a step-by-step timeline, let's focus on the attempts to replace HTML with something else.
Fast-forward to January 2000. The World Wide Web Consortium (W3C) recommended Extensible HyperText Markup Language (XHTML) 1.0. For an XHTML document to be served correctly, the author had to use the new application/xhtml+xml MIME type. However, Appendix C of W3C's XHTML 1.0 specification made provision for pages to be served by using the common text/html MIME type.
More than a year later, in May 2001, the W3C recommended XHTML 1.1. The abstract of the recommendation stated, "The purpose of this document type is to serve as the basis for future extended XHTML 'family' document types, and to provide a consistent, forward-looking document type cleanly separated from the deprecated, legacy functionality of HTML 4 that was brought forward into the XHTML 1.0 document types."
According to the abstract, XHTML was prepped to be the future of the web. The abstract boldly referred to HTML 4 as "deprecated, legacy functionality." And version 1.1 of XHTML removed the Appendix C version 1.0 provision that allowed a page to be served with the text/html MIME type. So why didn't this recommended standard replace HTML altogether? The answer is simple: Developers didn't implement it.
To be sure, many developers tried to implement XHTML in their websites. XHTML mandated a well-formed XML document using the classic HTML tags. To be well-formed, a web page would need to be served with no overlapping tags and no missing end tags, and the values of all attributes had to be enclosed in quotation marks. The notion of cleaning up our web pages wasn't unpopular, but it wasn't strictly enforced either. And even if a web developer created a well-formed web document, was it served with the application/xhtml+xml MIME type? Likely not. In fact, it is estimated that 99 percent of web pages on the Internet today contain at least one violation of the XHTML standard, which, if enforced, would cause the page to stop rendering and post an error to the end user. Ouch!
So now what? Exactly. WHAT was born. The Web Hypertext Applications Technology (WHAT) Working Group, actually known as WHATWG, came into existence in 2004 to put life back into HTML. This group's intent was to move forward in a manner consistent with how the web was actually being used and to spearhead innovations in HTML while maintaining backward compatibility. Instead of breaking 99 percent of the web, why not embrace the way in which web pages are actually served? Browsers have been forgiving. Why make page-breaking changes?
Therefore, the WHATWG came up with Web Applications 1.0 while the W3C worked toward version 2.0 of XHTML. However, near the end of 2006, it was clear that the WHATWG was gaining momentum while XHTML 2.0 was lacking support by any major browser. Thus, the W3C announced it would collaborate with the WHATWG. One of the outcomes of this union was to rename Web Applications 1.0 as HTML5.
Is there a lesson in this for us? Absolutely. Despite noble aims and grand ambitions, whatever the masses choose to adopt wins. The growing adoption of HTML5 makes it the winner. HTML5 cannot be ignored. Our brief history lesson demonstrates that HTML5 is here because we willed it to be here. (For more in-depth coverage of the history leading up to HTML5, check out Mark Pilgrim's Dive Into HTML5.)
Start Using HTML5
Although HTML5 is not an official specification yet, it achieved WC3 Candidate Recommendation status as of December 2012, which means that HTML5 is on the cusp of being the industry standard for web development. HTML5 already has a prominent place in website development, given that the major browsers are incorporating HTML5 features and Microsoft's recently stated intention to incorporate native HTML5 in Windows. In light of these changes, it's a good idea to start getting familiar with HTML5 now—and you can do so without making dramatic changes to the pages you already have. Let's consider a minimalistic HTML5 document, such as in Figure 1.
<title>A relatively minimal HTML document</title>
Notice the omission of the <html> and <head> tags. According to the current specs, this is still a valid document. If these tags are omitted, the browser will still parse the document, and the tags will be implied. This represents a shift from the strict conformity imposed by the current HTML standard.
Here is another example of how easy it is to adapt to HTML5:
The doctype syntax has been simplified. Compare this to examples of what we have been accustomed to, shown in Figure 2.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
The doctype declaration is required. Although it is clearly easier to type the normal HTML5 doctype, the deprecated doctypes in Figure 2 are still accepted formats. By the way, the doctype declaration is not case sensitive, so any of the following are acceptable:
<!doctype html> <!doctype HTML> <!DOCTYPE HTML>
Now take a look at Figure 3 to see a more realistic starting point for an HTML5 document.
<title>Getting Started With HTML5</title>
You might find slight differences in this HTML5 document compared to what you are used to. Apart from the doctype, you might notice the attribute on the <html> tag and the contents of the <meta> tag. Let's focus first on the <html> tag:
The lang="en" attribute informs the browser that the contents of this document are in English. This is much simpler than the following:
<html xmlns=http://www.w3.org/1999/xhtml lang="en" xml:lang="en">
Look at how much was removed. There is no longer any need to specify the namespace of the document because all elements in HTML5 (unless otherwise noted) belong to the XHTML namespace. The xml:lang attribute is left over from the XHTML era. So, once again, HTML5 presents a simpler way to do things, but for what it is worth, the older syntax is still acceptable.
Now, how about that <meta> tag? This is how we used to handle it:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
And as you have noticed, it is now this simple:
Of course if you want to use the old style, that's still okay. It's a good practice to make this meta charset tag the first child of the <head> tag because the specification states that the character encoding declaration must appear within the first 1024 bytes of the document. Why set the encoding for the document? Failing to do so can cause security vulnerabilities. Although the encoding can also be set in the HTTP headers, it's still a good practice to declare the encoding in the document.
These subtle differences clearly confirm the WHATWG's commitment to maintaining backward compatibility while allowing changes that simplify or enhance HTML. However, not everything from the past is preserved in HTML5. For good reason, some tags, such as those in Figure 4, have been given a proper burial.
Tags such as <basefont>, <big>, <center>, <font>, <strike>, <tt>, and <u> are purely presentational in their function and are better handled through CSS. In addition to these retired elements, a number of attributes have been removed for similar reasons. All absent or removed items in HTML5 can be found on the WC3 reference page.
New Features in HTML5
But what about the changes that give us new features in HTML5? Let's briefly consider some of the more popular additions that you can start using today.
First are the new elements that are in line with how the web works today. These new tags, shown in Figure 5, are structural or semantic in nature.
|<article>||For independent content, such as blog post or article|
|<aside>||For content slightly related to primary content on page|
|<figure>||For grouping a section of standalone content, such as video or an image|
|<figcaption>||For use with <figure> (optionally) to provide a caption|
|<footer>||For providing author, copyright data, etc.|
|<header>||For introductory content, could include navigation|
|<hgroup>||For grouping <h1> to <h6>|
|<nav>||For content intended to provide navigation|
|<section>||For a section in a document; similar to sections in newspapers|
A good number of websites today have very similar structures. Think of footers, for example: Many sites display footers, which usually contain author information, links, and copyright information. A typical HTML approach to footers would look something like this:
<div id="footer">© Copyright 2011 Egan & Palermo</div>
How many <div> tags would you guess there are on the web functioning as the container for footer information? Well, the count is so high it became obvious that a tag was needed to represent this information. In HTML5, the tag looks like this:
<footer>© Copyright 2011 Egan & Palermo</footer>
The main purpose of semantic elements is to provide context to the data. These tags are not about how the content looks. Rather, they are more concerned about the substance of the content. You modify the appearance of these elements through CSS.
The <input> tag in HTML5 supports new attribute types, shown in Figure 6.
|Input Attribute||Type Value|
|color||Hexadecimal color value|
|datetime||Date and/or time|
|datetime-local||Local date and/or time|
|search||Intent to search|
Although not all browsers support these new attribute types, it is clear that these types will map nicely with our modern entry forms.
Audio and Video Capabilities
Support for multimedia via the <audio> and <video> tags is another welcome addition to HTML5. What used to require a plug-in is now accomplished with simple HTML5 tags. Getting started is very easy. Observe the following markup and the screen shot in Figure 7.
<video src="big_buck_bunny.mp4" controls>
Sorry, your browser does not support the video tag.
With just a few lines of code, you can have a video up and running with interactive controls for your users to manage! The controls attribute can stand by itself, or you can use controls="controls" to provide the XML-friendly approach. Also, note that within the tags you can provide optional text that will be displayed if the browser does not support the video tag. As you select your video formats, remember that not all browsers support the same video types.
If adding video seems easy, HTML5 makes it just as easy to add audio to your site. The markup is fairly similar:
<audio src="music.mp3" controls> Sorry, your browser does not support the audio tag. </audio>
Like the <video> tag, the <audio> tag contains a controls attribute for visual display to manage volume and positioning of audio, as Figure 8 shows.
Although this example features an MP3 audio file, be aware that not all browsers support the same audio types.
A very exciting addition to HTML5 is the <canvas> tag. With this new feature, developers can add rich graphical experiences to their web pages. Think of a canvas as you would visual art in the real world. A painting canvas is usually a blank rectangle waiting to be drawn or painted upon. Likewise, in your web page, a canvas is a designated section of the page that you can draw on. By using the <canvas> tag, you eliminate the need for plug-ins that provide animations. Here is an example of how to declare a simple <canvas> tag:
<canvas id="myArtwork" width="200" height="200"> Your browser does not support the canvas element. </canvas>
To what degree can the <canvas> tag enhance the user experience? You really must try it yourself to experience the difference. However, to give you an idea, Figure 10 presents a screen shot of the game "Pirates Love Daisies." This tower-defense game is packed with action, animation, and stimulating sounds. It is so well done that you might find yourself doubting it is a pure HTML5 page.
Another striking demo that showcases a variety of HTML5 features, including Scalable Vector Graphics (SVG) support, is found at director.bonjovi.com. This page, shown in Figure 11, allows a fan to drag and drop clips onto a circular timeline, add effects, and publish a custom Bon Jovi video.
Web storage represents another nice addition to HTML5. Web storage is a highly anticipated feature that allows larger amounts of data to be stored locally in the browser without generating a performance hit on round trips. The primary way developers handle local storage today is through cookies. The disadvantage of cookies is that the data is passed back and forth with every HTTP request or response.
Note that in the preceding example, DisplayName was made up on the fly. The property name can be whatever you want it to be.
No Better Time to Be a Web Developer
What we have covered so far is just a taste of the new features in HTML5. This is an exciting time to be a web developer! Whether you are developing publicly for the web or creating internal sites for your company, HTML5 has much to offer in providing sorely needed features that are native to the browser. With growing support among all the major browsers and with new sites emerging that consistently use it, HTML5 is a must-visit technology for any serious web developer today. In the next article of this series, Dev Pro editors will focus on why leveraging HTML5 is important for ASP.NET developers in "HTML5 for the ASP.NET Developer."