Leave No Browser Behind: An HTML Adoption Strategy
But as much as the development and browser communities are pushing the HTML5 hype up to a fever pitch, the vast majority of people on the Web aren’t using the brand-new browsers and versions that we are. If you’re a Web developer in a large development shop or an enterprise with a large user base, you probably already know this. Even if you’re working with a small shop or startup providing some service via the Web, you probably spend a lot of time making sure your site caters to as many browsers and browser versions as possible.
Given this reality, it’s easy to see HTML5 not in terms of whether it’s ready to be used today, but whether you’re ready for it. For example, let’s suppose you’ve created a page with some of the new semantic tags (like <header> and <article>), added some new CSS features (like border-radius and box-shadow), and even added a <canvas> element to draw an HTML5 logo on your page.
In newer browsers like Internet Explorer 9, Firefox 4 and later, or Google Chrome, this will render as depicted in Figure 1. But if you attempt to load this page in Internet Explorer 8 or earlier, you’ll see something more like Figure 2: an utterly broken page.
Figure 1 A Semantic Page with Styles and an HTML5 <canvas> Element, Rendered in Internet Explorer 9
Figure 2 The Same Semantic Page, Rendered in Internet Explorer 8 with No Styles and No <canvas>
I wouldn’t blame you if you looked at all of the great features of HTML5 and, after having an experience like this, told yourself that the best course was to wait. It’s easy to come to the conclusion that, ready or not, HTML5 isn’t quite ready for you, or your users.
Before you make the decision to set a date in 2022 to take another look at HTML5, I ask that you read the rest of this article. My goal this month is to give you practical strategies for how you can adopt HTML5 technologies today without ending up with the kind of graceless degradation illustrated in Figure 2. In this article, I’ll cover:
These three subjects should tell you much of what you need to know to build Web sites for a broad spectrum of browsers. By the time we’re finished, you’ll have a solid strategy for adopting HTML5 technologies with confidence and without delay. You’ll also have some tools you can use to progressively enhance sites for newer browsers, while gracefully degrading for others.
The Importance of Feature Detection
This technique, known as UA sniffing, is widely used for determining which browser is requesting your page. The logic is that by knowing the user’s browser (Internet Explorer 7, for instance), you can make runtime decisions about what features of your site to enable or disable. UA sniffing is tantamount to saying to the browser: “Who are you?” (For an in-depth analysis on UA sniffing and other detection techniques, see http://jibbering.com/faq/notes/detect-browser/.)
The problem with this approach is that browsers can be made to lie. The UA string is a user-configurable piece of information that doesn’t really provide a 100 percent accurate picture of the browser in question. What’s more, as this technique became widely embraced, many browser vendors added extra content to their own UA strings as a way to trick scripts into drawing incorrect assumptions about which browser was being used, thus routing around detection. Some browsers now even include a facility that allows users to change their UA string with just a few clicks.
The goal of UA sniffing was never to know the user’s browser and version, though. And it certainly wasn’t intended to give you an avenue to tell your users to “go download another browser” if they used one you didn’t like—even if that technique is used by some. Users do have a choice in the browser they use, but our responsibility as developers is to provide the most reliable and consistent experience, not to impose an opinion of browser preference upon them. The goal of UA sniffing was always to give you an accurate picture of the capabilities or features that you could leverage within the user’s current browser. Knowledge of the browser itself is just a means to that information.
Today there are alternatives to UA sniffing, and one that’s growing in popularity—thanks in part to both jQuery and Modernizr—is called object or feature detection. These terms are mostly interchangeable, but I’ll stick to “feature detection” for this article.
The goal of feature detection is to determine if a given feature or capability is supported on the user’s current browser. If UA sniffing is like asking the browser “who are you,” feature detection is like asking the browser “what are you capable of”—a much more direct question and a more reliable way for you to provide conditional functionality to users. It’s much tougher for users and browsers to fake or erroneously report feature support, assuming feature detection scripts are correctly implemented.
Manual Feature Detection
So what does feature detection look like, as opposed to the UA sniffing example? To answer that, let’s look at fixing the issues that arose when viewing my HTML5 page, depicted in Figure 1, in Internet Explorer 8 instead of Internet Explorer 9. The markup for this page is listed in Figure 3.
Figure 3 A Page with New Semantic HTML5 Markup
The differences between Internet Explorer 9 and Internet Explorer 8, as shown in Figures 1 and 2, are drastic. For starters, my page is completely unstyled, as though the CSS for this page doesn’t exist. What’s more, I’m missing the fancy HTML5 shield at the bottom of the page. Each of these problems can be fixed easily, and feature detection is the first step to identifying the problem.
That’s feature detection at its most basic. With this statement and others like it, I now have a more reliable way to query feature support within the browser.
Using Modernizr for Feature Detection
Manual feature detection is certainly an improvement on UA sniffing, but this approach still leaves you to do the heavy lifting for both detecting the availability of a feature and deciding what to do if that feature doesn’t exist. And while the canvas example was a simple one requiring one line of code, this isn’t the case for every feature you may want to detect—nor is the detection code the same across all browsers. Detecting support for the CSS3 modules I used earlier (border-radius and box-shadow), for instance, can be a bit trickier.
We won’t discuss the first item any further in this article, though I encourage you to head over to modernizr.com and check out the documentation on this and the rest of the features.
The second item is the feature that helps turn this line of code:
Into this line of code:
This returns a Boolean indicating whether the canvas element is supported on the page. The great thing about using Modernizr as opposed to rolling your own feature detection is that Modernizr is a well-tested, robust and widely used library that does the heavy lifting for you. Twitter, Google, Microsoft and countless others use Modernizr, and you can too. With the ASP.NET MVC 3 Tools Update (released in April 2011) Microsoft even ships Modernizr in the box with new ASP.NET MVC applications. Of course, all I’ve accomplished at this point is detecting whether the <canvas> element is supported. I haven’t said anything about what to do next. Given the knowledge, via feature detection, that a feature is or isn’t available to a browser, a common next step is to create some conditional logic that prevents certain code from executing if a feature doesn’t exist, or executes an alternate path, similar to this:
Adding features to your site based on the presence of additional browser capabilities is referred to as “progressive enhancement,” because you enhance the experience for a more capable browser. At the other end of the spectrum is “graceful degradation,” where the absence of certain features does not cause the browser to error or fail, but rather presents the user with some diminished feature or alternative capability. For older browsers, graceful degradation doesn’t have to be your default option. In many cases, it may not even be your best option. Instead, with the assistance of Modernizr, you can often use one of many available browser polyfills to add HTML5-like features to non-supporting browsers.
What Are Polyfills?
By adding a reference to Modernizr on my page, I do get one immediate polyfilling benefit related to the example in Figure 3. The page rendered unstyled because Internet Explorer 8 doesn’t recognize tags like <article> and <header>. And because it didn’t recognize them, it didn’t add them to the DOM, which is how CSS selects elements to be styled.
Figure 4 An HTML5 Page in Internet Explorer 8, with the Help of Modernizr
Beyond its use to add support for new HTML5 elements in Internet Explorer, the Modernizr library doesn’t provide any additional polyfills out of the box. Those you provide yourself, either from your own scripts or from the ever-growing list of options documented on the Modernizr Web site. As of version 2.0, Modernizr provides a conditional script loader (based on yepnope.js— yepnopejs.com) that helps you asynchronously download polyfilling libraries only when needed. Using Modernizr with one or more polyfilling libraries that provide the features you need is a powerful combination.
Using Polyfills to Simulate HTML5 Functionality
Figure 5 Using Modernizr to Polyfill Canvas Support
Here, I’m using the Modernizr script loader to specify three things:
In the context of canvas, this is all I need to add some intelligence and polyfilling to my application. Modernizr will asynchronously load excanvas.js only for browsers that don’t support canvas, and then will load my script library for drawing the HTML5 logo on the page.
Let’s look at another example to underscore the value of Modernizr. The detail-oriented among you may have noticed that the site styled in Figure 4 isn’t quite the same as the original page, as rendered in Internet Explorer 9 and depicted in Figure 1. The page, as seen in Internet Explorer 8, is missing a box-shadow and rounded corners, and I couldn’t possibly ship this awesome site without either, so we’ll appeal to Modernizr again for help.
As with canvas, Modernizr can tell me that the CSS3 modules aren’t supported, but it’s up to me to provide a library to polyfill them. Fortunately, there’s a library called PIE ( css3pie.com) that provides both modules in a single library.
To add support for border-radius and box-shadow, I can add the code in Figure 6 to my script after I’ve downloaded PIE. This time, I’ll test to see if either the border-radius or box-shadow modules are supported (as opposed to assuming both are always supported or not) and if either is unsupported, dynamically load PIE.js. Once PIE has finished loading, I’ll execute a piece of jQuery to select all of my <article> tags and call the PIE.attach function, which adds support for the border-radius and box-shadow styles already defined in my CSS. The end result is depicted in Figure 7.
Figure 6 Using Modernizr and PIE to Add CSS3 Support
Figure 7 CSS3 Support with Modernizr and PIE
Using Polyfills to Aid in Graceful Degradation
In addition to using the polyfilling techniques discussed here, you can also leverage Modernizr to assist in cases where you wish to gracefully degrade your application, as opposed to polyfilling in another library.
Let’s say I have a Bing Maps control on a Web page, and I want to use Geolocation—which we’ll cover in depth in a future article—to find the user’s current location and then place that location as a pushpin on the map control.
With Modernizr, it’s a simple load call to one of two scripts I’ve created, as illustrated in Figure 8. In this case, I’m testing the Modernizr.geolocation property. If true (“yep”), I’ll load my fullGeolocation.js script, which will use the Geolocation API to find my location (with my permission) and place it on a map, as illustrated in Figure 9. If, on the other hand, the test is false (“nope”), I’ll load a fallback script that displays an address form on my page. When the user submits the form, I’ll use the provided address to center and pin the map, as illustrated in Figure 10. This way, my page provides a great experience to modern browsers, while degrading gracefully into a reasonable alternative for older ones.
Figure 8 Using Modernizr to Provide Graceful Degradation
Figure 9 Mapping with Geolocation
It’s easy to look at some of the advanced features of HTML5 and, in the face of a large user base still on older browsers, decide that your site isn’t quite ready for them. But there are great solutions already available that not only aid in graceful degradation, but also provide the capability to bring those older browsers into the present so your users can experience HTML5 right now. Over the course of this article, you’ve seen that with feature detection, Modernizr and polyfilling, it’s possible to adopt HTML5 without delay for the ever-growing segment of your users with a modern browser—all the while being careful not to leave the rest of your user base behind.
About the Author
Thanks to the following technical experts for reviewing this article: Damian Edwards, Scott HunterandClark Sell
Training and Certifications
All Developer Centers and Hubs