It slipped by me that just last week—a few days before Canberra’s first BarCamp—Eric Meyer wrote an article responding to Johnathan Snook’s announcement that he doesn’t use reset stylesheets. Following that came Jens Meiert’s arguments that reset style sheets are bad.
I can see where Jens is coming from but don’t see any compelling reasons that would convince me they’re inherently bad. Below I’ve tried to counter some of the common arguments that get raised against reset style sheets.
Overriding the overridden
The addition of extra lines in the author’s style sheet to override reset sheet definitions can become a waste of time and effort. The amount of definitions that need to be redefined comes down to two things: how many definitions are made in the reset sheet and the scope of the website.
Some large projects may even demand for an optimized production set of style sheets with a separate commented and split development set. A designer will need to decide how many definitions are going to be made in the reset style sheet and weigh that in turn to the redefinitions that need to be made. This should be combined with the use of optimization tools such as CSSTidy and of course the removal of redundant definitions from both the main style sheet(s) and reset sheet. See Going nuts, below.
Latency
Another style sheet in the mix will definitely add to the full download size of a website. Again this is relative to how large the reset sheet is. It is possible to compress CSS, (X)HTML, and Javascript files. With the YUI reset style sheet sizing at around four kilobytes, the optimization of images and their are implementation within the design is a more prevalent issue.
Removing functionality and usability
Removing usability through the reset sheet and neglecting to implement it by other means or redefining it is not an inherent fault of the reset sheet but of the designer; the designer should look into what elements the reset sheet is defining—never copy and paste blindly.
Going nuts
Reset style sheets aren’t bad because some are all-encompassing in their definitions and this certainly shouldn’t be a case for never using them. Ultimately the number of definitions in a reset style sheet should come down to how useful each is going to be in your project.
I take Eric Meyer’s position on this whereby we should use the tools that suit us best:
“The key here […] is that you evaluate various tools by thinking about how they relate to the ways you do what you do—and then choose what tools to use, and how, and when. That’s the mark of someone who thinks seriously about their craft and strives to do it better.”
Thus:
- Use what suits you best, even it’s just the age old
* { margin: 0; padding: 0; } - If you use a reset style sheet make sure you know what you’re resetting and why.
6 comments
The only thing missing from this post is… what’s a reset style sheet?
Good article. As I basically said on Jen’s blog, I don’t think using a “reset” style sheet is a black-and-white issue; as with most things in web development, it depends on the requirements of the project.
@chesty: “reset” style sheets are CSS files that reset elements defined by user agents (UA), such as a web browser. UAs will define styling for the basic (X)HTML elements in differing ways. The idea here is to provide you with a clean slate to work with by setting all of the values back to sensible defaults.
Of course “sensible” is the operative word — it is possible to go somewhat overboard with reset style sheets but in general they can be highly useful. Examples of reset style sheets can be found in the YUI library and Google’s Blueprint library.
Not to say that reset style sheets are bad, but they’re something I’d never use myself—what I want to control, I (re)set myself, when it comes to important aspects of the overall design, I set everything exactly anyway, and the rest the user can chose soi-même, or let the UA do the honours, of course. If I care how exactly lists look, I manually set them without unsetting some margins beforehand, but usually, I just leave the defaults.
Latency is really a non-issue. There are probably more important things to optimize than the load latency of a few 4k stylesheets.
Most modern web browsers and servers do everything over HTTP keep-alive, so it’s not particularly expensive for a client to GET another file.
If you’re *really* worried about latency, there are various projects around that combine your stylesheets into one big one.
@Lindsay Holmwood: Indeed — like you say “it’s very much like grasping at straws”.