5 Questions: No Browser Left Behind: An HTML5 Adoption Strategy

Every month, the 5 Questions blog series follows up on features and columns published in the current issue of MSDN Magazine. This month, I follow up with Brandon Satrom, Microsoft developer evangelist and author of this month's feature on HTML5 development, titled No Browser Left Behind: An HTML5 Adoption Strategy.

Michael Desmond: You recommend feature detection over UserAgent (UA) sniffing, as a way to accurately determine what a connected Web browser will support. Is this approach viable for all extant browsers?
Brandon Satrom: Feature detection is the best approach for all browsers old and new. Since the majority of feature detection practices use JavaScript to query the presence of global objects and properties, or support for newer DOM elements and attributes, these checks will work anywhere JavaScript is supported and enabled. I would never recommend UA Sniffing as a reliable indicator or feature support since the UA string can be manipulated. That said, there are some edge cases (for example, pre-loading script files via image beacons or object tags) where Feature Detection is difficult or impossible. Even in these cases where browser sniffing is needed as a last resort, I‘d recommend the use of conditional comments (https://msdn.microsoft.com/en-us/library/ms537512(v=vs.85).aspx) over UA sniffing.

MD: Modernizr sounds like a powerful tool for managing the HTML5 transition. What issues or complexities do developers need to look out for when employing Modernizr? Is there a performance penalty or other overhead associated with the JavaScript shims you talk about to enable HTML5-like functionality?
BS: Any tool like Modernizr comes with a host of considerations like overhead, performance and even cost-benefit considerations. On the performance end, Modernizr has both a low overhead in size and in the initialization for your site. Not only is the Modernizr library small (less than 6k for the minified base production version), but it performs nearly all of its work on-demand, if and when you check for support for a given feature. Modernizr.com also provides a custom build option where you can select only the tests and features needed for your site, so the resultant script file is as small as possible.

For your JavaScript shims, which are usually external scripts or libraries that you rely on to provide support for a newer feature in an older browser, I would always recommend using a script loader (like LABjs, jQuery’s $.load or yepnope.js, which the Modernizr.load feature uses) to only load shims when needed. This reduces the script burden for browsers that already provide native support. Of course, adding these scripts to older browsers does add to the overhead for those users, so developers should weigh how essential the polyfill in question is to the user’s experience on their site.

MD: From a broader perspective, do you have any advice for organizations intending to rely on Modernizr to enable HTML5 support? Are there certain features of HTML5 that might be problematical or issues related to potential movement in the formative HTML5 spec?
BS: The general advice I give to anyone looking to adopt Modernizr is this: Your first step is determining which HTML5, JavaScript and CSS features you are looking to implement in your site. For each of these, you should then determine if the presence of this feature will degrade or “break” the experience for a user with an older browser (for example, using a new JavaScript API like Geolocation will throw script errors in IE8). For these cases, you’ll need to branch your code with a feature detection operation, which you can write yourself or rely on Modernizr to do for you. Finally, you should determine which features you want to shim or “polyfill” for users with an older browser. Here, Modernizr will help with the feature detection piece, but you’ll need to provide the shim. The good news is that there are great shims for many of the HTML5 features, and several are listed at Modernizr.com.

The bottom line: Figure out what HTML5 features you want to use, what using them will do to a user with an older browser, and if you want to add that feature to older browsers via a shim. If, based on that assessment, you think a feature detection solution will help you, use Modernizr and be sure to pay attention to revision and improvements to it and any of the Polyfills you choose to adopt.

MD: Your mapping example showing graceful degradation is enlightening. But it does bring up the question: Are there situations where it is better to degrade gracefully, rather than attempt to mimic HTML5 via polyfills? Are there any guiding rules that help developers make these decisions?
BS: This is a fantastic question. I think the choice of degrading versus polyfilling for any developer would probably be based on some combination of the following factors: One, is the feature in question essential to the user experience of the site, or just a nice to have? Many CSS3 modules like border-radius probably fall into this category. Two, is a well-supported, robust polyfilling solution available, such as the jQuery Corners Plugin or PIE for CSS3 features? And three, does the polyfilling solution provide a faithful implementation of the feature, or is it merely a loose approximation?

The third question is pretty important as some features are easy to polyfill with JavaScript and CSS, while others, like Geolocation and IndexedDB can be a bit trickier. That’s not to say that polyfilling these types of features isn’t possible because solutions do exist, but developers should be aware that these solutions may not be as mature. I actually chose Geolocation for the graceful degradation demo because I think it’s a good example of where you can add great functionality (find my location for me) for users with a modern browser, while not breaking the experience for others (I’ll just tell you where I am.)

MD: What are some of the biggest misconceptions about HTML5 in the developer community? And what are some misconceptions about Microsoft’s stance with regard to HTML5?
BS: I think the biggest misconception about HTML5 in the developer community is the term itself. It’s one of those things that’s filled with so much hype and buzz that, in some ways, it’s lost its meaning. Technically, HTML5 really only refers to a small set of specifications managed by the W3C that deal with things like semantic markup and processing rules for user agents (browsers). In practice, though, HTML5 has been co-opted (by browser vendors, the W3C and others alike) to instead be an “umbrella term” for pretty much anything new and interesting in HTML, CSS and JavaScript proper. One definition I’ve heard is “HTML5 is everything after HTML4.” I know this mismatch bothers a lot of developers, but, to me, the bottom line is that Web standards are important to everyone, and we all win as a result.

As for Microsoft, I think the biggest misconceptions are that we aren’t: a) adopting Web standards (HTML5); b) adopting Web standards fast enough; or, c) adopting the given set of standards that a given developer deems most important. To be fair, I think this is a criticism that is leveled at just about every browser vendor by everyone, so we’re not alone in that.

But the truth is, IE9, was a huge leap forward for Microsoft’s commitment to Web standards in the browser. We implemented a ton of great features like canvas, SVG, Geolocation, semantic markup, a bevy of CSS3 modules and more. But we didn’t stop there. IE9 was also a work in progress, which is why we followed up with the first Platform Preview of IE10 less than two months after the release of IE9 (we’re now on Preview 2, by the way). It’s easy to look just at the current RTM’ed browser and form an incomplete conclusion about Microsoft’s commitment to Web standards, but the full picture can only be seen when you look at IE9, the IE10 Platform Preview, IE Test Center and HTML5Labs.com.