Begin Anew: CSS Resets

We love that feeling of starting new whether it’s fresh laundry, saving video game progress or that first sip of Guinness. In tribute to that spirit, let’s begin anew with CSS Resets. Most developers use a CSS reset in some form but there are many points to consider in deciding what is right for your design or how you can improve what you currently use.

These days, the issue is not whether to use an “official” reset or not but what form of one. That’s a surprisingly interesting topic we’ll look at along with a brief history, common usages and framework adaption.

The Purpose of a CSS Reset

Browsers have different preset defaults and by applying a CSS reset, you can make them behave more consistently. I like to think of it as a bunch of browsers chilling out at a bar having a few beers when suddenly their neurotic buddy, Internet Explorer 6 shows up. As any good friend would do, you’d lubricate him a bit to keep the night on track.

On that same note, we have to try to code responsibly as well. While I don’t think it’s wise to try to go reset commando, customizing your own reset as per your project needs… is the key. (Resetting in moderation?)

There are a couple of situations we should particularly be aware of when using any reset from my experience. The first is scalability and the second is working within a content management system (CMS) or third party software… but first a note on personal preference.

Personal Preference

The Web Standards community nixes the notion of pixel perfect consistency between browsers these days and I agree. However, speaking as a designer and developer — website design becomes more intricate everyday. It’s not very appealing to code an intricate design with the different variables of each browser in the air.

That’s my personal preference based on my skill level, work flow, team, experience and the types of projects that I build for my clients. I primarily use a customized version of Eric Meyer’s CSS Reset and continually evolve it to suit my needs.

There is nothing sinful working with a browser’s default styles but I’d sooner choose a Bud Light over an Anchor Steam.

Scalability

Often with web programming, when size comes into play it is prudent to give careful consideration to how the code will perform on a larger scale. Scalability always reminds me of a poorly planned family road trip where my sister and I became the meat in an “Auntie Sandwich” in the back seat of our Toyota Tercel. How quickly one wishes they planned ahead.

Awkward family moments aside, the most immediate factor you can evaluate is which CSS styles you are resetting in relation to what your content is. Eric Meyer’s CSS Reset covers the gamut of HTML attributes and was created on the thought of implicitly declaring an attribute value. That may be overkill for websites on a smaller scale. In this use case, it might be a good idea to prune the reset of some of the less frequent attributes for maximum efficiency. Less is more in this instance.

On the other end of the scale, the reset itself is just more overhead code and implicitly declaring every value adds even more to that kilobyte count. In this use case, it may be wiser to ride as many browser defaults as possible and reduce the reset to the bare essentials. Then carefully organize your external style sheets for an efficient cascade and attach individual resets as necessary.

For example, a global style sheet with basic font resets might be in order because every page template probably has some text content. Specialized page templates with forms might do well referencing a style sheet with isolated form styles with a form reset. This type of strategy would leverage a lot of the positives of using a reset while being efficient with resources.

A lot of the projects I work on to be middle of the road in terms of scale and not surprisingly — that might be why I am a proponent of CSS resets. My projects require I use a large gamut of HTML attributes without having to be too much of a KB curmudgeon. In this case, it may be overkill to focus on resource management when it’s more important to be nimble with content layout and flexible with CSS declarations.

Content Management Systems and Third Party Software

Seems like there are as many CMSs out there as Paris Hilton has boyfriends and each one of them are as creative as Lady Gaga’s outfits. Yup, I went there but you know it’s true.

The great thing about CMSs is that if you’re working on a large website, you’re using one. If you’ve had the pleasure of cherry picking one, you’re aware they often come built in with useful features that help with scalability… and CSS resets!

Typically, a quality CMS will have options for caching different file types like CSS and have a versatile and flexible templating system where you can apply conditionals to customize layout templates with CSS. This of course allows you to develop a plan for how you want to deploy your CSS in the most efficient manner as your project dictates.

Third party software like a CMS will often have utility templates that handle membership, registration and the like. It would be in your best interest to evaluate whether to reuse existing default styles or develop your own. Keeping them segregated might be the key as having to customize an entire third party app may not be a part of the job scope.

The best case scenario is if your development environment allows you to be flexible with CSS deployment as a built in feature. If not, it becomes another layer of complexity for your website that may possibly lead to alcoholism.

Actual Usage

Brief History

If you have set your margin and padding to zero, then you’re been using a bare minimum form of a CSS reset. Think about what you’re doing — resetting the margin and padding to zero.

Looking back around 2006/2007, it was an interesting time in web design. Flavors of Internet Explorer, Firefox and Safari were much less consistent than they are now. (Suicide rates among web developers have dropped subsequently since then.)

CSS pioneer Eric Meyer started writing about CSS resets in 2001 and provided a baseline kit on his website. He encourages users of the reset to customize it for their own projects and will update it on occasion.

You can find the original post and reset kit here:

• http://meyerweb.com/eric/thoughts/2007/04/18/reset-reasoning/
• http://meyerweb.com/eric/tools/css/reset/

Other forms of CSS Resets include the Yahoo YUI version found here:

• http://developer.yahoo.com/yui/reset/

Or you can look through the parade via a great post from Jeff Starr outlining the major differences between the resets:

• http://perishablepress.com/press/2007/10/23/a-killer-collection-of-global-css-reset-styles/
• http://perishablepress.com/press/2008/03/23/more-killer-css-reset-styles/

I find that they are more alike than they are different. They vary depending on:

• Comprehensiveness of HTML
• Fonts and font sizing
• Browser targeting

Implementation

It only makes sense to use a CSS Reset at the first cascade to clear all styles and build from there. My projects usually build external CSS in this order:

1. CSS Reset
2. CSS Grid Framework
3. Global CSS via Localized and Object Oriented Classes
4. Specialized/Isolated CSS Classes

Summary

The browser wars are back and let’s face it — asking the browser boys for any kind of consistency is like herding cats. Try to set the table to your liking and Begin Anew.