Modernizr: Code For Success Or Failure? - Part 1

Modernizr: code for success or failure? - part 1

I'm getting my feet wet with the Modernizr feature detection library . This has led to a new dilemma in implementing the design: should you test for success or failure?

In other words, what are you assuming about your users? Are you assuming that most of your users have advanced browsers that are capable of immediately rendering advanced features and you need to provide alternatives only to the older browsers? Or, do most of your users have older browsers that will need a more traditional default state with overrides in place for a smaller percentage of advanced users?

For this project, the user base is split almost 50/50 between different versions of IE and a combination of Safari and Chrome (and almost no Firefox, which I find odd). So one half of users are capable of seeing almost any of Webkit's bleeding edge advances. The other half of users has the worst support for emerging standards amongst the major browsers. It was definitely new ground for me.

In the end, I opted to progressively enhance the user experience and tested for success. I assumed that most users will not have bleeding edge support for CSS gradients, RGBa, border radius, or multiple backgrounds. Modernizr's success-state classes on the html element provide hooks to add these features. Let me know if you've found compelling reasons to offer fallbacks for older user agents.

I'm thinking of creating a part 2 that plays devil's advocate for the opposite point of view. I need to do some tests, but I can definitely see potential performance by cutting backwards compatible images and their additional requests.