Browser Patches, Shims, and Polyfills
I’ve noticed that the jQuery community has started using the term Polyfill recently so here’s a brief post that helped me in thinking through this topic. It’s largely inspired by the awesome list of HTML5 Cross Browser Polyfills assembled by the Modernizr folks.
Graded Browser Support
Yahoo has published their Graded Browser Support for the last 3 years and it makes a great starting point for any web application project. More recently jQuery Mobile published their Mobile Graded Browser Support which emulates Yahoo’s approach. Both of them have divided browsers into tiers, Yahoo choosing to provide different experiences to users in different tiers, and jQuery Mobile choosing to only support the top tier.
The tiered approach is a great way of thinking about the browser landscape and outlining a strategy for Progressive Enhancement or Graceful Degradation. However there are still significant variances in the APIs of the browsers within a single tier, especially if you want to use any of the newer technologies. Developers address this variance by writing Patches, Shims, and Polyfills(?) in the hopes of creating a baseline API on which to build the rest of their application or library. Generally your baseline API should target current W3C and related specs.
Building Patches, Shims, and Polyfills
If you’re Google and you have unlimited engineering resources you can write sophisticated browser plugins like Chrome Frame and Google Gears to update older browsers. For the rest of us, the best way to go about writing patches, shims, and polyfills is to use feature detection (as opposed to user-agent detection). Peter Michaux has a great article on how feature detection balances false positives and false negatives. You can also learn about feature detection techniques from Dive Into HTML5. There are a number of feature detection libraries such as jQuery.support and Modernizr.
A Polyfill is essentially a shim that replicates the real API as defined by the standard/spec.