What Does It Mean For A Business Software Vendor To Support HTML5?
(Technical Summary)

This is the second version of this blog; the first one was aimed at non-technical decision makers, but this second one is aimed at developers.

Irrespective of the version you read, the purpose of this blog is to cut through all the marketing phluff, hype and general disinformation that has grown up around HTML5 and get down to the hard facts.

My approach focuses first on examining whether the correct question is being asked, and secondly, on the various standards and recommendations that exist for the functional capabilities of a browser. This will act as the groundwork for establishing a technically accurate description of what HTML5 actually is. Only then we can start to address the opening question of what it means for a software vendor to “support” HTML5.

More Hype ’n’ Phluff ’n’ Stuff

Remember all the hype that AJAX generated 6 or so years ago? Well, history seems to be repeating itself; but this time, the name “Ajax” has been substituted for “HTML5”.

Even though there are an increasing number of websites dedicated to showcasing and explaining what HTML5 is, the public perception of HTML5 still seems to consist of 9 parts disinformation, hype and marketing phluff, mixed with 1 part hard fact.

So, What Really is the Question?

Albert Einstein was once asked by a journalist the following question:
“What would you do if you knew that in 1 hour, the earth would be hit by an asteroid that could destroy all life on the planet?”

Einstein replied:
“I would spend 55 minutes defining the question, and 5 minutes answering it.”

Extracting the HTML5 facts from the phluff will require exactly the same approach. Once we have carefully defined the question, answering it should be very straight forward.

So What Is HTML5?

The most accurate description of HTML5 is to say that it is the next major revision of HTML, the language used to build web pages. However, this description is not particularly helpful since many people do not have a clear understanding of what the term “HTML” actually describes.

In addition to this, through the indiscriminate use of hype and marketing phluff, the media has expanded the term “HTML5” such that it is now little more than a generic, blanket term covering a wide range of new, Web-based features that you may (or may not) find popping up in the shiny new browser you’ve just installed.

In order to de-phluff the whole “What is HTML5?” question, we must first backtrack few steps and look at how standards for the Web are defined and who defines them.

Is There A Standards Body For The Web?

Yes: this organization is the called World Wide Web Consortium (W3C) and was founded (and is currently chaired) by the man who invented the World Wide Web, Tim Berners-Lee.

In addition to the W3C, there is the Web Hypertext Application Technology Working Group (WHATWG). Formed in 2004, the WHATWG is a community of individuals all interested in evolving HTML and its various related technologies. It was formed by a small group of people who had become somewhat frustrated – not only by the slow progress made on standards development by the W3C, but also on the W3C’s 2004 decision to abandon HTML in favour of XML.

Independently of the W3C, the WHATWG took it upon themselves to develop a major revision of the W3C’s current HTML standard known as HTML4. This is where the term “HTML5” was first used.

Then in April 2007, the WHATWG proposed that the W3C adopt their new HTML5 proposal as the starting point for their work. This proposal was accepted and, as of May 2007, the W3C took on WHATWG’s specification for HTML5 as their official proposal for the new HTML standard.

How Is The W3C Organised And What Standards Do They Define?

The W3C exists as a community of individuals, businesses, non-profit organizations, universities and government bodies who have made it their task to bring agreement to the development of software standards for the World Wide Web. The W3C has an Advisory Committee that oversees the process of standards recommendation.

As of January 2011, the W3C had 324 members.

The W3C defines standards not only for HTML, but also for many other areas of Web based software. These include:

As you can see, HTML is just one of many different standards defined by the W3C.

How Long Does It Take For The W3C To Create A Recommendation?

Well, let’s just say you shouldn’t hold your breath waiting.

There is a well-defined process through which all recommendations pass, starting with the initial idea and finally ending up at a formal recommendation. These stages of maturity are as follows:

Working Draft (WD)
This is the first publicly available version of a standard that is open for comment by anyone. Working drafts go through multiple, possibly disruptive revisions.
Candidate Recommendation (CR)
The group responsible for the particular standard is now satisfied that the functional requirements have been achieved. At this point, the development community is approached to determine how viable the standard is as working software.
Proposed Recommendation (PR)
It has now been agreed that the standard both achieves its functional requirements and can be implemented as working software. It is then submitted to the W3C Advisory Committee for approval.
W3C Recommendation (REC)
The Advisory Committee has approved the standard and now issues it as a formal W3C recommendation. At this point it becomes a defined standard to which Web-based software should conform.

The time it takes to get an initial idea to progress through these stages of maturity varies widely and in some cases, can be quite long. For instance the third revision of the Cascading Style Sheet standard (known as CSS Level 3 or just CSS3) started in 1998. This standard is still being worked on in 2011!

Once A W3C Recommendation Is Made, What Then?

Having a standards body for Web based software is all very good and necessary, but the W3C has no direct authority to enforce the adoption of any of its recommendations. Therefore, browser vendors have implemented only those new features that best suited their development timescales and/or corporate goals. This piece-meal approach to feature development has created a high degree of inconsistency between different browsers and has been a major source of heart-ache and pain for Web developers – just ask any Web developer how much extra time, effort and expense is required to get a website to function equally well in not just different browsers, but different versions of the same browser.

In spite of the fact that the bureaucratic processes of the W3C move like a speeding glacier, the hype and media interest surrounding HTML5, together with the fact that the Web has become a ubiquitous part of our business and social lives, has provided sufficient incentive for the major browser vendors to implement many of the new W3C features long before they ever reach even the Candidate Recommendation stage.

Consequently, the picture today for inter-browser compatibility is still not perfect, but is looking better than it has done in the past.

So Where Are We Up To With HTML5?

Back in 2008, Ian Hickson, the editor of the HTML5 specification, quipped that he did not expect HTML5 to become a full W3C Recommendation before 2022. Fortunately, he has since revised that opinion and stated that he expects HTML5 to reach the Candidate Recommendation stage in 2011, and become an official W3C Recommendation by 2014.

Writing this blog in February 2011, 2014 still seems like quite a long way off; but unlike the adoption of HTML4 and CSS2 over a decade ago, browser vendors have not waited for the W3C to give the green light; they have just gone ahead and implemented the features anyway. This is largely because browser vendors can achieve many functional advantages through early adoption of the W3C’s proposed new features – regardless of the fact that most of the proposals are still at the Working Draft stage.

So let’s look at what HTML5 actually is and what it can offer.

HTML5 – What Is It Really?

As we have seen from the previous section, the W3C is currently working on multiple proposals for how Web based software should operate. These recommendations cover a wide range of functionality that includes:

HTML & CSS: Defines the structure for a web page’s content and how it should be presented
Scripting and Ajax: Adds dynamic, asynchronous refresh capabilities to a web page
Graphics: Defines which picture formats are supported
Audio & Video: Defines how audio & video content can be handled without the need for plug-ins
Accessibility: Defines how web pages can be accessed by people with disabilities
Mobile Web: Defines the standards for accessing the Web from mobile devices

These topics are just some of the many currently being dealt with by the W3C. However, if you look at all the different features that the media are labelling as “HTML5”, you will find that they are drawn from many different W3C proposals – only one of which is actually called HTML5.

So when the term “HTML5” appears in common usage, it is typically being used simply as a generic term to cover a wide variety of new, browser based features – and not simply the single W3C standard called HTML5.

OK, So Why All the Confusion?

The confusion comes from the fact that many people (even those who are technically literate) assume that anything displayed by a browser can be described as “HTML”. This immediately creates a high degree of ambiguity around what the term “HTML” actually means. Over time, this rather vague use of the term “HTML” has come to include:

JavaScript
Cascading Style Sheets
Scalable Vector Graphics
And a variety of other browser based technologies, as the whim of the individual takes them

A Potted History of the Development of Browser Functionality

In order to understand why we are where we are today, we need to take a look at where we’ve come from.

The first publically available description of HTML was published by Tim Berners-Lee in late 1991. This outlined the basic concept of HTML and included the first 20 tags – 14 of which still exist in the current standard.

That’s all very well, but what then is HTML? OK, let me put on my “pedantic university professor’s hat”.

HTML is a mark–up language used for describing the
content and general layout of information in a document.

This means that when you write an HTML document, you need to add special markers, or tags, around the blocks of text in order to instruct the browser how that text should be displayed. The HTML tags themselves are never displayed, but are used by the browser to recreate the author’s intended layout for the document.

For instance, if you take the German pangram: “Victor jagt zwölf Boxkämpfer quer über den Sylter Deich” and wish to have this displayed as a paragraph, you would enclose the text within a pair of tags starting with <p> and ending with </p> thus:

<p>Victor jagt zwölf Boxkämpfer quer über den Sylter Deich</p>

This pair of tags instructs the browser that all the text between them is to be treated as a single paragraph.

The above example is very basic, but it illustrates the point that HTML is nothing more than the set of tags used to describe the text, images and hypertext links in a web document.

From Static to Dynamic

Back in the mid–nineties when Netscape was king–of–the–browser–hill, it was quickly recognised that a web page created from static HTML was pretty dull; the reason being that once the HTML page had been written, that was it – it was static. So the Netscape Corporation decided that they could steal a march on their competitors by giving their browser the ability to run programs contained within the HTML web page. After considering various options, the name “JavaScript” was chosen for this new programming language.

These new, JavaScript–enabled browsers could now dynamically change their own HTML content in response to user actions. This meant that web pages could become a whole lot smarter and no longer needed to call their Mamma (the web server) for help.

Now the simple browser had become more than just a tool for presenting static information; it was turning into a runtime environment for programs written in JavaScript.

Now that HTML had acquired a complementary technology called JavaScript, the confusion started to creep in.

HTML does not require the use of JavaScript, neither does JavaScript require the use of HTML. Neither technology depends upon the other, yet because they were designed to function in a complementary manner, and always appeared in public together, they acquired a conjoined identity.

Blurring the Boundaries (and Other Style Sheet Properties)

Looking at the timeline diagram above, it can be seen that alongside the JavaScript story, another development was taking place.

As soon as professional design and graphics artists got hold of HTML, they started to push it way beyond the bounds of its original capabilities – and very quickly ran into boat loads of trouble.

HTML mark–up tags were fine on their own for defining the major elements of the document, but they had very limited capability when it came to the fine details of presentation.

Originally, Netscape approached this problem by creating various new HTML tags that could describe the relevant presentation information. For instance, the <font> tag was used to present text using different typefaces:

<font face="Curlz MT">Victor jagt zwölf Boxkämpfer... </font> <font face="Essays 1743">Victor jagt zwölf Boxkämpfer... </font> <font face="Underwood1913">Victor jagt zwölf Boxkämpfer... </font>

However, these new tags started to blur the boundaries between page content and page presentation.

The W3C reasoned that it made little sense to combine the instructions for content presentation with the instructions for content definition, so when the HTML4 standard was published in December 1997, those tags that existed only for presentation purposes were deprecated in favour of the new kid on the block called Cascading Style Sheets or CSS.

The concept of a style sheet is to separate the instructions needed for presentation from the HTML instructions that define the contents of a web page. Typically, the style sheet information lives in one or more separate files that are requested by the browser as a result of processing the HTML file.

Sheets Are So Stylish!

A style sheet works simply on the basis of pattern matching. The browser examines the contents of the HTML file and applies any styles it finds that match the given patterns.

Using the German pangram example above, if you wish to instruct the browser to display a paragraph using a particular typeface, then rather than using the <font> tag within the HTML document, you would specify the style to be applied to that block of text.

Style sheet information can either be included in the same file as the HTML, or it can be stored in a seperate file. Using a style sheet held in a separate file, the HTML would look something like this:

<html> 
<head>
  <link rel="stylesheet" href="main.css" type="text/css"> 
</head> 
<body>
<p>Victor jagt zwölf Boxkämpfer quer über den Sylter Deich</p> 
</body> 
</html>

The <link> tag instructs the browser to load a style sheet file called main.css which, in this simple example contains the following information:

p { 
  font-family: "Underwood1913"; 
}

Notice that the paragraph tag (<p> ... </p>) contains no formatting information whatsoever; it simply states that the enclosed text is to be treated as a paragraph.

The browser examines this style sheet and finds it has a selector with the pattern “p” (meaning the <p> paragraph tag). As the browser renders the HTML, it encounters the <p> tag and finding a positive match with the CSS selector, applies the rules contained within the curly brackets—which in this case is simply the command to display the text using a type face called Underwood1913.

This produces exactly the same result as before:

but does so without blurring the boundaries between content and presentation.

There is a huge amount more that can be done with style sheets and the above description barely scratches the surface; but all this to say that Cascading Style Sheets allow you to specify in a single file, a consistent look and feel for an entire website without ever having to alter the HTML content.

Two becomes three…

So now we have a second complimentary technology called Cascading Style Sheets that, together with JavaScript, expands a browser’s capability to present HTML documents.

When a browser receives an HTML page from a web server, it processes the HTML and may possibly, have to perform 2 other types of processing:

Process the HTML instructions. (This always happens)
This may lead to subsequent requests for one or more...
JavaScript files (to make the HTML/CSS content dynamic)
Style sheet files (to make the content look pretty)

Since these distinct types of processing all take place within the browser, people have mentally lumped all three areas together into a generic category known simply as “HTML”.

Whilst this is not completely wrong, it has introduced significant ambiguity into the meaning of the term “HTML”.

Here Comes HTML5...

As we have seen from the previous section, the public perception of “HTML” is best described as “anything that happens inside a browser”.

Now that the W3C and the WHATWG have started working on improving browser functionality, it was a natural, though incorrect, step for people to continue to refer to all browser based functionality, new or old, as HTML.

Only this time, the number “5” has been added to the name.

So what can HTML5 do for me?

The simple answer is “A whole lot more than HTML4 + CSS2 + JavaScript could ever do”. However, there’s a sting in the tail—and this is the part that is often omitted from the glowing descriptions of HTML5 you’ve probably read.

Unless you use a modern browser to display your fancy new HTML5 web page, it will look no better than before—in fact, it will probably look worse.

Here’s a high level look at some of the features in the W3C's draft proposals (generically known as “HTML5”).

Semantic HTML

Semantic HTML gives a web designer the ability to construct a web page in a manner that is relevant to the content of that page and does not force the use of arbitrary mark–up tags.

For instance, if you are writing a blog, you may want to divide the content of your document into a navigation area followed by various sections, then it is natural to think in terms of these structural units rather than having to press–fit your structure into something like a <table>.

Unfortunately, HTML4 does not let you structure your document in this manner. In HTML5 however, you can now structure your document in a manner that reflects the document’s content:

<!DOCTYPE html> 
<nav>Navigation content...</nav> 
<section> 
   <header>Header text</header> 
   <article>Lorem ipsum dolor sit amet...</article> 
   <footer>Footer text</footer> 
</section>

Notice that in HTML5, the usual <html> and <body> tags are not required; however, leaving them out will confuse older browsers. Therefore, for the sake of backward compatibility, these tags should always be included.

New Form Types

When creating an input field on an HTML form, you now have an extended range of input field types:

<input type="email" value="name@domain.com">
<input type="date" value="2011-02-25" 
       min="2011-02-01" max="2011-06-30">
<input type="range" min="0" max="100" value="50"> 
<input type="number" min="-50" max="50" value="0"> 
<input type="search" results="20" 
       placeholder="Search...">

Direct Multimedia Support

Prior to HTML5, if you wanted to play any audio or video content on your webpage, you had to rely 3^rd party software plug–ins; the most widespread being Adobe’s Flash Player.

The W3C has now proposed that browsers should be able to play audio and video directly using the <audio> and <video> tags. This means that 3^rd party plug–ins are no longer a necessity.

<audio src="sample.mp3" controls></audio>

<video src="pr6." preload controls></video>

Scalable Vector Graphics Support

The W3C has proposed that browsers should provide direct support for Scalable Vector Graphics. However, this proposal is nothing new; it was first proposed as an open standard back in 1999, but vendor adoption was slow. In truth, this feature has long been supported by all the major browsers except for Internet Explorer (up to and including version 8).

An SVG image uses an XML file format that describes 2–dimensional, vector based images. These images can either be static or dynamic (interactive or animated).

As the name implies (and unlike raster or bitmap based images), SVG images can be scaled up or down in size without the creation of artefacts or the loss of image quality.

This is because the XML file that describes an SVG image does so by describing not the pixels in the image, but the shapes (points, lines, curves and colours etc), text and gradients etc that are required to recreate that image. These instructions are then executed within whatever display area happens to be available for the image.

Not only can images be used as the source property of an <img> tag, but using the <svg> tag, “inline svg” can be defined. This means you can now directly enter the image information inside the HTML document. In other words, graphs or charts can now be dynamically created inside the browser using JavaScript to create the relevant SVG information.

JIT Compilation for JavaScript

All major browsers now contain a “Just–In–Time” (or JIT) compiler for the JavaScript language.

The need for JIT compilation is not covered by any W3C specification; however, browser vendors are well aware of both the fundamental importance of JavaScript in modern web pages, and the performance benefits that come with JIT compilation. Consequently, this feature has been added without a W3C proposal.

Traditionally, programming languages have been executed in one of two runtime modes. These are static compilation (ahead–of–time) or “interpreted from bytecode”. JIT compilation takes a hybrid approach by translating the bytecode into machine instructions at runtime, but then caching the results to improve efficiency in the event that that same block of code is called again.

Now that all the major browsers implement JIT compilers for JavaScript, it has become feasible to implement larger applications directly in the browser.

Extended JavaScript Functionality

Here is where some of the most significant differences can be found between HTML4 and HTML5. The following list of features is just a selection of what could be achieved in an HTML5 compliant browser.

Web Storage: Save key/value pairs on the client that persist after page refreshes or browser crashes.
Indexed Database API: Define your own databases for the storage of client side objects.
Web Workers: This is multi–tasking JavaScript. The biggest benefit of this feature is that long running or expensive computations can be run as background tasks that do not block the user interface.
Web Socket: A browser can “upgrade” its HTTP protocol connection to a WebSocket (WS) protocol connection. This is to provide web servers with a valid data push mechanism out to clients and avoids the need for the current approach of maintaining long running HTTP connections.
Web Sockets are still fairly experimental and the specification for this feature is not yet completely stable.
Drag and Drop Support: A variety of JavaScript events related to dragging and dropping objects are available including ondrag, ondrop, ondragenter, and ondragleave
Geolocation: If the client device running the browser can provide geolocation information, then this can be obtained in the browser through the navigator.geolocation API.

New Features in Cascading Style Sheets

As has been mentioned above, HTML4 often forced you to house your content in a construct that bore little or no relationship the content’s semantics. However, taken together with the new semantic tags such as <section>, <article> and <aside> etc., the new features in Cascading Style Sheets (known collectively as CSS3) greatly improve the separation between the semantic content of your web page and the style information used to format that content.

Here’s a small selection of what can now be achieved using CSS3:

CSS Selectors

If you want to style alternate rows of a table or alternate items in a list differently, then use the following selector:

tr:nth-child(even) td { background: #EEEEEE; } 
tr:nth-child(odd) td { background: #FFFFFF; }

The values odd and even used as parameters to nth-child are short forms for the normal 2n+1 and 2n respectively.

You can also apply a style only to those elements having a specific attribute value:

input[type="number"] { background: #D0D0D0; }

Using Fonts Not Installed on the Client

Have you ever thought it would be nice to use a particular type face for your web page, but then decided against it because you thought it probably wouldn’t be available on most people’s machines?

Well, now you don’t have to worry about that any more—enter the @font-face selector. (Actually, this selector has been around for quite a while, but never saw widespread adoption.)
This selector allows you to use a type face that if missing from the client, can be uploaded from the web server.

@font-face { 
  font-family: 'Essays 1743'; 
  src: local('Essays 1743'), 
       url("/tt_fonts/Essays1743.ttf") format("truetype"); 
  font-weight: normal 
  font-style: normal; 
}

Columns

If you want a text block to wrap automatically into 2 columns separated by a 2em gap and 1 pixel line, then use the following CSS (note that the CSS instructions have to be specified three times in order to account for the vendor specific prefixes –webkit– and –moz–)

column-count: 2; 
column-rule: 1px #bbb; 
column-gap: 2em; 
 
-webkit-column-count: 2; 
-webkit-column-rule: 1px #bbb; 
-webkit-column-gap: 2em; 
 
-moz-column-count: 2; 
-moz-column-rule: 1px #bbb; 
-moz-column-gap: 2em;

IMPORTANT!
This feature may not work in Webkit or Gecko based browser without first adding a browser specific prefix such as -webkit- or -moz-. To cover the fact that you don’t know which browser will be used to view your website, all three versions of these parameters can be used as shown above.

Rounded Corners

This seems to be the one feature everyone thinks of when talking about HTML5. The official CSS selector is border-radius, but as described above, you may need to add the -moz- or -webkit- prefix.

Well this is great! But you keep saying there’s a problem?

There are many other CSS3 features that could be described here, but the problem is that there is no guarantee that these features are supported by any particular browser.

And this is the heart of the problem.

By now, I trust it is apparent to you that there is a potentially large mismatch between what you could do with HTML5, and what any given browser will let you do.

“Oh dear! This is not quite the rosy picture painted
by all the marketing peeps and drive-by analysts...”

No, it isn’t… So the next question is this:

“How can I make use of all the cool new features in HTML5, yet at the same time,
deliver an app that will function in the customer’s browser?”

Here is where browser based applications need to get smart and dynamically adapt their behaviour based on what browser they find themselves running in.

Browser Detection vs. Feature Detection

At this point, many Web developers will immediately cry “Browser detection!” and trot out a piece of JavaScript coding like this:

if (navigator.userAgent.indexOf('MSIE') > -1)

If this test returns true, then it is concluded that the browser must be Internet Explorer, and that it will therefore be capable of certain functionality.

Well, that logic would be fine and dandy if it weren’t for the fact that many browsers allow the user to spoof the userAgent string. In other words, you can make your browser look like any other browser; so conclusions drawn from testing the value of this string cannot be considered conclusive.

Another flawed technique is not the following test, but the conclusion drawn from its outcome.

function supportsCanvas() { 
  var elem = doc.createElement('canvas'); 
  return !!(elem.getContext && elem.getContext('2d'));
}

This function implements a perfectly valid test for checking whether a browser (any browser) supports the new <canvas> tag. However, the fatal flaw in the logic to conclude that if this function returns true, that the browser must therefore be Internet Explorer.

This is like saying if an object has wheels, then it must be a car. Well, all I can say to that is:

“Go directly to jail. Do not pass Go. Do not collect £/$/€200”

The answer to browser detection is don’t do it! The name used by the browser to identify itself is of almost no consequence. What really matters is detecting what capabilities the browser has.

Implementing Feature Detection

The simplest solution here is to perform explicit feature detection. You could either write these tests yourself or use a tool like Modernizr.

Modernizr is not the only tool available that performs feature detection, for instance, jQuery offers similar functionality. However, at the time of writing this blog (Feb, 2011), Modernizr seems to be the most comprehensive feature testing tool available and as such, very nicely illustrates the key problem with the use of HTML5; namely, that the new functionality being loosely described as HTML5 may—or may not—work in your browser. Let me say that the other way around. Your choice of browser will critically determine whether or not a given piece of HTML5 functionality will be available or not.

This Open Source JavaScript based tool checks the functionality of whatever browser it finds itself running in and then does two things:

It adds labels to the class property of the <html> tag to indicate whether or not the checked features are possible in the current browser.
For instance if the browser cannot play HTML5 audio or video, but can render borders with round corners, then the <html> tag’s class property would be modified:
<html class="no-video no-audio borderradius">
You can then create a CSS style sheet with specific selectors for .borderradius or .no-borderradius and specify what is to happen under these different circumstances.
Also, a Modernizr object is created that can be queried at runtime.
Using the above example, if (Modernizr.borderradius) returns true, but
if (Modernizr.video) returns false.

For instance, if you want to show a video clip, then you can do something like this:

if (Modernizr.video) { 
  document.write('<video src="movie.mp4" poster="flyer.jpg" controls></video>'); 
} 
else { 
  // Output the HTML to show the video in a 3rd party plugin 
}

Not only is this type of feature detection very reliable, but it also allows you to code your applications such that they can make use of any HTML5 features supported by the current browser.

CAVEAT!
The only time when you should be concerned about the exact name and version of a browser is when known bugs need to be coded around. For instance, it might be that you know a specific version of a browser adds say, 2 pixels of padding around a button; so in this case your application would need to be concerned about the exact browser name and version in order to code around this bug. But apart from this situation, you should not need to care about the value of the userAgent string.

So What Does Modernizr Think of the Major Browsers?

The following table shows the different features tested for by Modernizr and whether or not the major browsers support that feature.

Modernizr is not to be used as a tool for providing a definitive yes/no answer to the question "Does this browser support HTML5?"; however, it is safe to assume that the tests performed by Modernizr constitute a practical and reliable method for determining how well a browser supports the most widely used features of HTML5.

The top row above the browser name shows the name of the rendering engine used by that particular browser (because this is where the real support for HTML5 happens).

The capabilities of your browser are shown on the right–most column under the heading “My Browser”. Your browser reports the following about itself:

User Agent:

Feature	Chrome 9.0.597.94	Firefox 3.6	Opera 11	IE 9
	Webkit	Gecko	Presto	Trident
@font-face
Canvas
Canvas Text
HTML5 Audio
HTML5 Video
rgba()
hsla()
border-image
border-radius
box-shadow
text-shadow
opacity
Multiple backgrounds
Flexible Box Model
CSS Animations
CSS Columns
CSS Gradients
CSS Reflections
CSS 2D Transforms
CSS 3D Transforms
CSS Transitions
localStorage
sessionStorage
SVG
SVG Clip Paths
Inline SVG
SMIL
Drag and Drop
hashchange
X-window messaging
History Management
applicationCache
Web Sockets
Web Workers
Web SQL Database
WebGL
Indexed DB

The test results for Input Types and Input Attributes have been omitted from this table because these results are not simple yes/no answers. Also, the test results for the Touch and Geolocation APIs have been omitted as these are only appropriate for mobile browsers.

What about HTML5 support in older versions of Internet Explorer?

It is possible to give older versions of Internet Explorer a large degree of compatibility with HTML5. This compatibility can be achieved by adding the Microsoft specific HTTP header either to the value sent out by your web server:

X-UA-Compatible: chrome=1

Or by adding it to a <meta> tag in the <head> section of each web page:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

This header was added to achieve compatibility between different versions of Internet Explorer, but has now been extended to allow the Chrome Frame to be downloaded as a plug–in to replace the Trident rendering engine.

There has been some discussion about whether using the Chrome Frame plugin introduces possibility for security breaches — but these comments came from a less–than–pleased Microsoft spokesman who did not like it when Google announced that they had fixed the “Internet Explorer problem”.

So I Can Just Go Ahead And Build Cool New RIA Apps in HTML5!

Hold on a second there, Tiger!

As stated above, browser vendors have looked at the wide range of new functionality proposed by the W3C and adopted those parts that best suited their development schedules or corporate needs. Although the situation is better than it has been in the past, incompatibility still exists between different browsers with regard to support for the full range of “HTML5” functionality. (This is particularly concerning security topics such as XML HTTP requests.) So the bottom line is this:

You can build a business application using as many of these new, ambiguously named “HTML5” features as you like.

However, it’s your customer’s choice of browser that will determine whether or not your application will work.

So support for all these wonderful new “HTML5” features is provided by the browser used to display the application and not by the company writing the business application!

The limiting factor here is the customer’s choice of browser.

So Which Browsers Are The HTML5 “High Flyers” And Which Are The “Lame Ducks”?

As of Feb 2011, Google’s Chrome 9 and Apple’s Safari 5.0.3 offer the widest range of support for all the new features generically known as “HTML5”.

Coming in second is Firefox 4 which also has good support for “HTML5”, but it’s not quite as extensive as that found in Chrome or Safari.

Opera comes in third slightly behind Firefox 3.6 and somewhat further behind Firefox 4.0.

But trailing in a rather distant fourth place is Microsoft’s Internet Explorer 9. Internet Explorer 9 has some support for “HTML5”, but cannot yet understand many of the new features in HTML5 Forms and CSS Level 3.

Opinion is also divided as to whether IE9 has as much HTML5 support as is claimed. Microsoft claim it has around 99% HTML5 support, but the rest of browser–savvy world disagrees.

Now for the really bad news—if your customers are using Internet Explorer versions 7 or 8, or worse still, Internet Explorer version 6, then you have to make some tough decisions about the use these new “HTML5” features in your business applications. The fact of the matter is that these browsers simply do not understand any of the new tags, styles or JavaScript functionality.

The bottom line here is that you’re nowhere near the Promised Land of “HTML5” – instead, you’re wandering in the HTML4 wilderness without even having satisfactory support for CSS2.

How Do I Know What HTML5 Features Are Supported By Which Browser?

Various websites exist that will either present you with tables of which browser supports which feature, or the website will check the capability of your particular browser and give you a simple report. These include:

Can I Use?: Provides detailed information on which versions of which browsers support the various new features HTML5, JavaScript and CSS3.
HTML5 Readiness: Shows a radial barchart of which “HTML5” features are supported by the major browsers. Each bar is a hypertext link to the relevant W3C or WHATWG proposal.
Modernizr: A JavaScript based, Open Source tool that checks your browser’s “HTML5” functional capability. The results of these test are then available at runtime by interrogating the Modernizr object.

Ok, So Where Does That Leave Me?

It leaves you in the position of needing to have a clear understanding about which versions of which browsers your business applications will run in. Here’s how to proceed:

Check with your customer base and find out what browser(s) they are using. (The older the browser, the fewer your options).
Check to see which of the new “HTML5” features are supported by those browsers.
The list created in step 2) will then define the subset of true “HTML5” features you are free to work with.
Only then can you start to build an “HTML5” application that will work at your customer’s site.

What Should I Do If My Customer’s Browser Really Belongs In a Museum?

By museum piece, I really mean Internet Explorer 6, but these principles apply to any out–of–date browser.

Under these circumstances, it would be best to enter into discussions with your customers and explain that you would love to deliver them some shiny new, “HTML5” enabled applications, but until they start to use HTML5–enabled browsers, you are unable to provide them with up–to–date applications that deliver a modern UI experience.

If the customer is willing to upgrade their browsers, then you are free to use whatever HTML5 features are supported by the customer’s choice of browser.

If, however, the customer is either unwilling or unable to upgrade from their old version(s) of IE, then you can adopt one of three approaches:

Completely Ignore HTML5
In this approach, you would deliver your Web application using only those capabilities delivered by HTML4, JavaScript and CSS2. Generally speaking, your application will run successfully in both the old and new browsers; however, you should be aware that you:
- Must be willing to accept that the current limitations of HTML4 and CSS2 are less of a problem than a browser upgrade. (This might be the case if the customer has a mission critical web application that only functions in IE6)
- Will be unable to deliver an application that provides a modern UI experience
There should be a strong business case against a browser upgrade before this approach can be considered viable.
Deliver HTML5–like functionality using HTML4, JavaScript and CSS2
In this approach, you attempt (as much as possible) to make your application look and function like a modern “HTML5” based application—without actually being one. This approach is widely used at the moment by Web developers who want to make use of the benefits provided by “HTML5”, but are restricted by the limitations of browsers that do not understand the new HTML5 tags, JavaScript functionality or CSS3 style information.

Since this approach requires that HTML5–like functionality is re–developed using old technology, a Cost/Benefit analysis is strongly recommended before embarking on such an exercise.
Dynamic Adaptation
In this approach, you write your application such that it first checks the functional capabilities of the browser within which it finds itself running. Then the business application adapts the structure of its user interface to make use of the most modern features available. If modern features are not available, it falls back to the older techniques used in HTML4 and CSS2.

For instance, if your application wants to display a video clip, then it would first check whether the browser understands the <video> tag. If it does, then this tag is used; else, an Adobe Flash video is used instead.

This style of application architecture is said to “degrade gracefully”. As the application is run in progressively older browsers, its appearance and functionality slowly degrade in line with the browser's reduced capability.

The upside of approach is that it allows your application to be as browser independent as possible. However, the downside is that it requires extra time and effort to design and test an application with adaptive behaviour.

Here’s a Summary of What We Know

HTML5 is the next major revision by the W3C and WHATWG of the existing HTML4 standard.
However, in common usage, the term “HTML5” has become a generic term used to describe a wide variety of browser functionality drawn from many different W3C proposals—only one of which is actually called HTML5.
True support for this new functionality takes place in the browser and not in the business application.
A business software vendor can make use of as many of these new “HTML5” features as they like, but there is no guarantee that these features have been implemented in the browser used by their customers.
If your business applications need to accommodate the widely varying capabilities of old and new browsers alike, then the dynamic adaptation approach described above should be followed.

So let’s go back and look at the original question:

What Does It Mean For a Business Software Vendor to Support HTML5?

By now it should be clear that the word “support” is not the best choice of verb in this question. This is because the actual support for these new features takes places within the browser, and not in any application created by a business software vendor. So it is the browser that supports “HTML5”, and the business software vendor then writes an application that makes use of these various new features.

Unless you, the business software vendor, also write your own browser, then you are entirely reliant on the 3^rd party browser vendor to provide support for the various new “HTML5” features you wish to use.

Therefore in the above question, we should replace the word “support” with the word “implement” and also be a little more specific on what we mean by the term HTML5.

So the question now reads:

What Does It Mean For a Business Software Vendor to
Implement an Application That Uses the New Features found in
HTML5, CSS3 and JavaScript?

And I think you already know the answer to this question...

:-)

Chris Whealy

What Does It Mean For A Business Software Vendor To Support HTML5?(Technical Summary)