Modernizr, what an interesting tool you are. How do I use your class names in my CSS files? You’ve given me a choice and I’m not sure what to use:
.multiplebgs div p {
/* properties for browsers that
support multiple backgrounds */
}
.no-multiplebgs div p {
/* optional fallback properties
for browsers that don't */
}
There are two ways to view this, bottom up, and top down. They both have their advantages and disadvantages, and I’m going to attempt to highlight these for you, so you can make your own decision.
Bottom up
For the “bottom up” way of doing things, we define a lowest common denominator. A set of styles that will work with all the browsers your website is designed to target. The intersection of all the features of all your browsers, if you want to put it that way. From here, we use Modernizr to progressively enhance the user’s browsing experience for browsers that support particular features. An example may help:
a.btn {
background:transparent url(../img/btn-red.gif) no-repeat scroll 0 0;
padding:5px;
display:inline-block;
width:40px;
}
.borderradius a.btn {
background-color:red;
background-image:none;
border-radius:5px;
}
The advantages being:
- A clearly defined baseline that works on all browsers we’re coding for
- If we aren’t able to determine client features (because for example, Modernizr is not available: the CDN is down, or the client doesn’t have JavaScript enabled) we know that the baseline styles will be used and will ensure the site looks acceptable regardless
The disadvantages are:
- We end up writing more and more CSS as we utilise new features that become available
- It doesn’t encourage a particularly forward thinking coding practice. You’re essentially coding for the browser with the lowest feature set
- If you want to change the baseline styles because of a redesign or perhaps your baseline is raised, you’re probably going to have to change overridden styles in the progressive enhancement style blocks as well
Top down
The “top down” approach is where we define styles for new browsers, and then use the “no-” prefix classes to define exceptions for browsers that don’t support the feature we’re exploiting. e.g.
a.btn {
border-radius:5px;
background-color:red;
padding:5px;
display:inline-block;
width:40px;
}
.no-borderradius a.btn {
background:transparent url(../img/btn-red.gif) no-repeat scroll 0 0;
}
We’re forward thinking, assuming everyone viewing our site is using these great new features and coding in fallbacks for the exceptions to the rule. Our view is that one day, all browsers will support the styles we’re using…and we’re adding in exceptions for in the mean time. The advantages are:
- We end up writing less CSS, as we don’t have to override properties we’ve previously declared that the browser doesn’t understand
- Our mindset is altered slightly, encouraging us to make use of and exploit new browser features that allow us to code and prototype faster
- As our browser baseline increases, it’s really easy to remove exceptions that are no longer used
The disadvantages are:
- We’re totally relying on Modernizr and the browser having JavaScript enabled. Without JavaScript the “no-” prefixed classes are not added to the <html> element and the browser is left trying to style things that aren’t supported or use style declarations that don’t exist (as far as the browser knows).
Well, sort of. You could always use the “no-js” class on the <html> element which Modernizr normally removes and replaces with “js” (to indicate JavaScript is available). You’d define your styles as above, but then define a lowest common denominator style set, for when you don’t know what features a browser does or doesn’t support. That’s kind of overkill though.
So, that’s basically it. When I first thought about it my gut reaction was to sit in the bottom up camp, but after thinking about it, and considering the audience for the project I’m working on it makes more sense to use the top down approach. Especially now that I’ve written it down like this. I’m hoping it’ll help others to make the right decision.
Pingback: Tweets that mention Modernizr progressives or exceptions? | freestyle developments -- Topsy.com
Hi Alan,
Original creator of Modernizr here, wanted to thank you for writing this up, it’s a useful resource! I’m glad you went the Top Down approach, that is generally how we recommend using Modernizr but thus far we haven’t had a simple, clear resource explaining the differences to point to. Now we have.
Our reasons for preferring Top Down are the advantages you listed, but also: it creates a very clean and clear separation between what is our desired markup and CSS, and what is there only to serve as a fallback. Separating fallbacks from goals is a really good practice to get into, and a great mindset to have.
Lastly, we also consider the disadvantage minimal; yes, there are people with no JavaScript or for whom it is proxy-filtered out, but the reality is that the Web going forward will need JavaScript if it is ever to progress and flourish. As long as we make sure that core content is at least accessible without JavaScript, then everything should be okay to need JavaScript (in our opinion). That includes a nicer looking design and better interactivity and navigation. It’s for the sake of the Web in the long-term without sacrificing too much on the short term.
Thanks again!
I’ve mostly used Modernizr as a way to catch exceptions, so more of the top-down approach. It results in the most clean CSS and is easier to debug if something goes wrong.
Definitely a top-down kind of guy. I code for functional/capable browsers and use fallbacks/exceptions for the less-capable browsers.
I see you share interesting stuff here, you can earn some
additional cash, your blog has huge potential, for the monetizing method,
just search in google – K2 advices how to monetize a website