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.