I recommend using a reset stylesheet. Good ones make cross browser issues very few and speed up the development of the layout a lot in my experience.

Hands down

meyerweb.com: CSS Tools: Reset CSS ^[1]

Point

Yes, absolutely use a CSS Reset if you plan to develop for cross-browser compatibility. I've used YUI ^[1], Eric Meyer Reset ^[2], and an earlier one developed by Faruk Ateş ^[3] (from The Internet Archive ^[4]; Faruk Ateş new site ^[5]). One additional thing to keep in mind is that resets are designed to tear down differences. In most cases, this usually takes the form of removing padding and margins that would otherwise be inherent browser defaults.

Once you've torn down the differences, it's up to you to build up element padding and margins. If you find yourself in this situation, you'll probably want to look at the Stack Overflow question CSS Reset, default styles for common elements ^[6].

Counterpoint

You should also read counterpoint arguments against the use of CSS Resets. Jonathan Snook ^[7] says he doesn't use resets ^[8] and Eric Meyer ^[9] wasn't upset at all ^[10]. So there are folks who don't use resets and even some who actively discourage the use of resets ^[11].

Understanding both sides of the issue should help you make an informed decision as to whether they're right for you or not.

I have started looking at CSS frameworks and reset style sheets lately, and I have come to a basic conclusion.

Why reset? Set instead. Simply put, replace your reset style sheet with one that SETs all the basic styles to the defaults you would like to start from instead. You still get a good baseline across browsers by setting all your styles to a standard format. I just don't see the point of doing something to force me to specifically undo it later. I would much rather start with a style sheet that has a reasonable starting point that overrides the differences between browsers while at the same time making elements appear as I would expect them to everywhere.

So how about we see the death of the reset style sheet and the birth of frameworks with set style sheets. I think I will work on creating my own set.css in the near future.

I have developed my own reset.

 *{  
    margin:0;
    padding:0;
    border-width:0;
 }

This removes all padding, margin, and borders. If you are like me, you really only use a subset of HTML. When was the last time you used applet, abbr, acronym, address, big, cite, code, del, dfn, ins, kbd, q, s, samp, tt, var? I am not talking about that one time in that one project where you had a stroke of genius and found a real use for kbd and even if you did, the * will reset these tags.

I like this approach better than the conventional Eric Meyer approach because it:

1. Is less code
2. Does not require a second stylesheet, therefore less http requests
3. It works

I am interested in any comments, I have been using this 'framework' for more than five years and it has held up over time.

EDIT: I see a comment below the question talking about the wildcard selector as being slow. I just want to think about what we mean by slow. Should we be comparing the wildcard to tag selector rendering (therefore an internal CSS comparisons) or should we compare file size/http request (which is end user experience comparison)? I think of the saying "The forest from the trees".

Yes. Yahoo's YUI Reset ^[1] is a solid choice.

This is an old question but I just thought I'd add a disclaimer. CSS resetting can cause problems in situations where you need to render legacy presentational attributes. This may happen, for instance, with certain RichText editors, HTML webmail or older HTML generating code. CSS rules ALWAYS override HTML ones, even when the HTML values are on the element itself. This means your reset values will break something like <td valign="top"> when you reset td{vertical-align: baseline;} as done in the Eric Meyer example.

This is not to say you shouldn't consider reset css, just that it some situations it will cause problems of its own.

I like my CSS with the "C" for Cascading. I'm not a fan of _SS, which is what you get when global resets short-circuit cascading by globally styling content-level elements like td, th, p, etc.

Requirements for using a _SS global reset:

• Site cannot use third-party controls that rely on normal HTML rendering and CSS cascading
• Site must either a) not allow clients to paste content into it, OR b) have a client who knows HTML/CSS well enough to use inline styles to replace the HTML attributes that no longer work, OR c) have back-end scripts to convert HTML attributes to inline styles and CSS classes, so things like cellpadding="2" can add padding to cells. The scripts must also add !important to pasted inline styles, so things like <tr style="vertical-align:middle"> can override crap resets like td,th{vertical-align:baseline;}.
• If you can't be 100% sure that third-party controls and WYSIWYG editors will NEVER be added to the site in the future, then you will re-style EVERY reset tag, including those you aren't using yet, because others might use those tags in the future, and will expect them to render at least somewhat normally
• Page load time is not a concern (you'll have at least twice as much CSS as without a reset)

Use it for a personal portfolio site, or some other fun little site you can experiment with. Use it for prototyping and brainstorming ideas. Maybe for a unique promotional landing page that will have a short lifespan with few changes, or a page that's mostly flash. But in most cases, don't make life miserable for clients and other developers in the future by taking lazy shortcuts today.

CSS resets should be used only as a tool in the development. When you are just starting co slice up the design to ensure some sort of baseline.

But, do not use CSS reset in production code.

When you CSS/HTML is complete, there should not be any resets. You should have only the CSS rules which pertain to that and only that site. There is no point in setting reseting <h1> browser default just to change them again in your proper CSS.

Besides. It is harmful if you look at it from point of view of optimization. Usually you do not feel the difference , BUT , when you are using JS animation each change to the DOMElement.style object causes browser to do a Reflow operation. Which in turn has to recalculate the new stylesheet ( because it has change ). The more overriding rules you have , the slower the Reflow, which in turn can destroy the user experience. Especially if user is on a cheap netbook, instead of a powerful desktop computer built for high-end gaming.

You shouldn't, unless you have no choice ...

• You have two options:

  1. If you are working in a company that requires you to make a Pixel-Perfect layout in HTML (like what I do, which I hate). Then you'll have no choice but to use a CSS Reset. Pixel-Perfect is one of the main reasons why CSS Resets exist.

  2. On the other hand, if you recognize and understand that you cannot make your layout 'exactly' the same on all browsers, then congratulations; you have found the light, then CSS Resets definitely will not be of any use. I personally do not advocate using any CSS Resets because there are more important things to be concerned of than simply focusing on the presentation (or exactness) of your website.

  If you are in option 2: then simply focus on Progressive Enhancement; there are a lot more to consider than just having a Pixel-Perfect layout and/or design.

The goal of a reset should be to remove undesired default browser stylings where you are not adding your own stylings. For example if you have a site-wide styling for paragraphs it is pointless to have an earlier rule removing a margin/padding etc. from paragraphs and one applying them later.

However if you are styling your headings or unordered lists selectively then you will want a reset global styling to remove padding/margins etc. with special effects created by more specific rules like h3.articleSubheader or #navigation li.

I personally do not use a reset stylesheet, and would not allow anyone on my team to do so. Anyone who is sufficiently competent with CSS should just be able to set up their styles correctly from the start, without the need for this extra stylesheet, which just adds bulk to the page. One of the linked answers above sums it up nicely - why reset a bunch of styles just to override them with your own values?

I think it's a good idea and can really speed up web development.

A few comments about which one is better can be found in this question ^[1].

I think the guys at Html5Boilerplate ^[1] have accumulated the most "best practices" and their Styles.css contains an amazing reset. Here are the comments beginning the file that show what all they use:

001./**
002. * HTML5 ✰ Boilerplate
003. *
004. * style.css contains a reset, font normalization and some base styles.
005. *
006. * Credit is left where credit is due.
007. * Much inspiration was taken from these projects:
008. * - yui.yahooapis.com/2.8.1/build/base/base.css
009. * - camendesign.com/design/
010. * - praegnanz.de/weblog/htmlcssjs-kickstart
011. */
012. 
013. 
014./**
015. * html5doctor.com Reset Stylesheet (Eric Meyer's Reset Reloaded + HTML5 baseline)
016. * v1.6.1 2010-09-17 | Authors: Eric Meyer & Richard Clark
017. * html5doctor.com/html-5-reset-stylesheet/
018. */
019.

I definitely use a CSS reset. As others have stated it helps having a baseline to start with to reduce the number of quirks you may encounter when dealing with more complex styles across an array of browsers.

When I first read about the CSS reset, I thought it was a hack designed for the true fanatics. However, a recent project justified its use many time over when just making a consistent layout between Internet Explorer 6, Internet Explorer 7, and Firefox.

If you were just building an intranet website aimed at Internet Explorer 7, then it may not be that critical. However, it's a really low performance hit and helps in establishing a consistent style.

I don't think you want to set all tags to have no styles, what you should want is to remove browser specific nonsense and set standards for all elements. A reset is only half of that. It'd be nice to see fewer "resets" and more "sets".

For example rather than:

ul, ol, li{margin:0; padding:0; list-style:none;}

I have:

ul, ol{margin: .25em 0 1em 1.45em; padding:0;}
li{margin: 0px;padding:0}

If you like to use tags semantically running into a global generic reset can be a pain, because then you have to hack styles just to get back some decent defaults.

Yes, and I encourage you to use a CSS Reset, because you can more control your layout. I use Reset.css from Eric Meyer.