Every web browser has a default style sheet it uses when rendering content, and every web browser uses slightly different defaults. Perhaps a button will use an extra 2 pixels of width in one browser, but 3 fewer pixels in another. These differences are insignificant to many of us, but they worry some designers and keep them awake at night. This is where CSS reset style sheets come into play.
The goal of a CSS reset style sheet is to set the default styling for all HTML elements into a known state. A good CSS reset will effectively “undo” all the default styles any web browser might define. The CSS designer can then built their own style rules and feel relatively confident that a design will look the same across all browsers and environments.
For example, here is what you will be starting with after applying the YUI Reset CSS:
There are a few CSS resets available on the web:
Note that YUI and Blueprint both include a CSS reset as part of a larger CSS framework.
This is the subject of some debate.
Some people feel a CSS reset creates more work – both for the designer and the web browser. The designer has to start from scratch and will write more CSS style rules to design a page that has been stripped of all aesthetics by a CSS reset. Naturally the browser will also work harder to process all these additional rules and cascades.
But, if you care deeply a design, and how that design will render around the universe, then you won’t mind any of the extra work. CSS reset can be good.
As Eric Meyers says in his post “Crafting Ourselves”:
Reset styles clearly work for a lot of people, whether as-is or in a modified form. As I say on the reset page, those styles aren’t supposed to be left alone by anyone. They’re a starting point. If a thousand people took them and created a thousand different personalized style sheets, that would be right on the money. But there’s also nothing wrong with taking them and writing your own overrides. If that works for you, then awesome.
For others, reset styles are more of an impediment. That’s only to be expected; we all work in different ways. The key here, and the reason I made the approving comment above, 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.
Eric’s commentary applies to many of the tradeoffs we face in software development.
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#