HTML5: What Is It, Why Should I Care, and What’s Microsoft Doing About It?

Article
03/29/2011

HTML5. Unless you’ve been living under a rock, you’ve probably at least heard of it. But what is HTML 5, really?

Background

HTML5 is a bit of an overloaded term at the moment, which unfortunately leads to no small amount of confusion. Wikipedia has a bit of the history of the HTML5 specification process, but while that history does tell us that there are currently two separate groups (WHATWG and W3C) working on the HTML5 specification, it doesn’t really tell us much about what HTML5 brings to the table, or its scope.

HTML5 is also an umbrella term, indeed a buzzword, that is frequently used to encompass other new web technology specifications, such as CSS3, Geolocation APIs, Web SQL Database, etc.

Given two groups working on the standard, one might rationally wonder how that all works. Well, without getting too deeply into the history, one group (the W3C) was working on a separate specification (XHTML 2.0) which was long overdue, and which folks were worried would actually break much of how the web works today, by enforcing stricter standards in terms of how markup is constructed. Another group (WHATWG), didn’t want to wait around, and started working on HTML5 (originally referred to as Web Applications 1.0) in 2004. In 2007, the W3C adopted part of the work of WHATWG as the starting point for their HTML5.

Confused yet? Wait, it gets better. WHATWG now refers to their specification as simply “HTML” and calls it a “Living Standard” meaning that it will be developed and updated on an ongoing basis.

What’s in it for Me?

So why should you, as a web developer, care? HTML 5 has some real promise for making some of your tasks easier. New semantic elements like <header>, <footer>, <article>, etc. make markup more readable, and intuitive in terms of the purpose various elements on the page. CSS3, while not directly a part of the HTML5 specification, adds more control and improvements to rendering of page elements, allowing you to develop better looking applications with less hackery needed to make it happen.

And while they’re currently struggling with arguments over codec implementations in the various browsers (no one seems to be able to agree on a single codec), the <audio> and <video> elements hold promise of making it easier to embed audio and video in your pages and applications.

And related technologies, such as Geolocation APIs, provide easier access to functionality that previously required plug-ins, script hacks, or was just plain limited to native applications.

Is it ready, how do I use it, and is Microsoft supporting it?

This is where the rubber meets the road…implementation. And it’s challenging for developers because the truth is that HTML5 is not finished, a subject of no little discussion on the web. In fact, there’s even a tongue-in-cheek site devoted to the fact:

The answer from IsHtml5Ready.com

That being said, most modern browsers provide support for at least a subset of the overall HTML5 and CSS3 feature set. One challenge facing both browser vendors and developers is that parts of the HTML5 specifications and some modules of the CSS3 specification are still changing on a weekly basis. This means that both browser vendors and web developers should be aware of the maturity of particular specifications prior to implementation.

The solution for some vendors has been to implement draft specifications using vendor-specific prefixes. For example, Firefox and Safari added custom prefixes for adding rounded corners to elements, like so:

    1: .rounded
    2: {
    3:    -moz-border-radius: 5px;
    4:    -webkit-border-radius: 5px;
    5:    -border-radius: 5px;
    6: }

That’s 3x the CSS, before you consider any other browsers that may have custom implementations, and before you consider elements where you may want each corner rounded differently. Ugh! (and before folks complain, yes, I know that the current implementations of these browsers support the non-prefixed border-radius property…the point is whether or not such vendor-specific implementations make sense or not).

So how is a developer to figure out what’s supported? Well, I’ll start by telling you what NOT to do…DON’T sniff the browser version as a means of testing if HTML 5 is supported. Browser (user agent) sniffing is a big reason for pain in transitioning from version to version of browsers. Too many sites, for example, use(d) script to sniff for IE, and then make assumptions about necessary fixes that stopped being necessary as of IE 8 (or even IE 7 in some cases). Unless you really want to maintain some complex script that manages versions of browsers you’re targeting, write your code to the current standards, and if you want to take advantage of future-looking or draft functionality, follow a two-step process:

Detect the specific feature you wish to use.
Use polyfills (mild language warning) or other workarounds to add support where the feature is not available.

By using detection (either manually, or via a library such as Modernizr), you can focus on features, and not on browsers. Your code can degrade gracefully, shim with a polyfill, or whatever you choose, and when a newer browser is available that supports your desired feature, you won’t have any code to fix, the feature will simply work! Woohoo!

What’s Microsoft doing to help?

Microsoft has been very clear that for scenarios requiring the broadest possible reach, HTML5 represents the future. Internet Explorer 9 provides robust, standards-based support for the mature, stable features of HTML5 and CSS, and the IE team is committed to continuing to support a standards-based approach to feature implementation. You can read more about Internet Explorer 9 and HTML5/CSS3 at:

https://ie.microsoft.com/testdrive/Default.html

Additionally, Microsoft is committed to improving tooling for HTML5 development, and a major first step in that direction was the addition of HTML5 and CSS3 support in Expression Web 4, via Service Pack 1. My colleague Chris Bowen has posted a very nice write-up of the HTML5 and CSS3 functionality in Expression Web 4 SP1, which I highly recommend (both the post and the service pack).

Additionally, Visual Studio 2010 Service Pack 1 adds Intellisense statement completion for HTML5, and initial support for parts of CSS3.

Last, but not least, Microsoft has teamed with Template Monster to release a series of Razor syntax-based templates for use with the new Microsoft WebMatrix development tool (though they can be used with Visual Studio as well), some of which take advantage of the new semantic markup elements in HTML5. You can see an example of one of these templates in use at the Mid Atlantic Developer Expo site (while you’re there, consider submitting a talk, or registering for the conference).

You can safely assume that more improvements in tooling are coming, and that support for HTML5 and CSS3 (and related technologies) will continue to be added to Internet Explorer and Visual Studio and Expression Web as the specifications reach the appropriate level of maturity.

Conclusion

So what should you, as a web developer, take from all of this? Well, for starters, this discussion really just scratches the surface, so start reading up on HTML 5 (including this interesting history).

When you’re ready to move forward, keep the following in mind:

Go ahead and jump in with HTML5 and CSS3, but with the understanding that browser support varies, due to the fact that some of these specifications are a moving target, while others are sufficiently mature to support robust, cross-browser implementations.
Use detection techniques (or Modernizr) to determine whether a given feature is supported by your user’s browser, and use polyfills as needed to supplement where features are missing.
Take advantage of tooling in Expression Web 4 SP1 and Visual Studio 2010 SP1 to make building HTML5-enabled sites easier.

HTML5 is here to stay, and while it may not be completely finished, there’s value in testing the waters. Let me know what you think about HTML5, and Microsoft’s support for it, either by email, or in the comments.

Comments

Anonymous
March 29, 2011
And yet IE9 still doesn't support the new "input" types, and there's even some suggestion that it never will! Look at all the "no support" crosses in the IE9 column! :( http://wufoo.com/html5/
Anonymous
March 29, 2011
From: Adrian Bateman <adrianba@microsoft.com> "While we don't have immediate plans to support these controls in IE, ..." lists.w3.org/.../0047.html That was August 2009, so I guess "no immediate plans" means "no plans at all". :(
Anonymous
March 29, 2011
The comment has been removed
Anonymous
April 04, 2011
An apropos follow-up read to my recent post on HTML5 : team.silverlight.net/.../standards

Share via