Css Reset - What Exactly Does It Do

CSS reset - What exactly does it do?

In the beginning, there was no standardisation on how styles worked, each browser implemented what it felt was right. One of the reasons you see so many questions about style errors in IE is because IE was the browser with the most dissimilarities from other browsers in terms of styling. Though IE has improved and so have other browsers they still apply their own borders, padding and margins, zoom, fonts to elements to give their own unique feel to pages. One example is, chrome gives its own yellow borders to text boxes. The "reset" actually "resets" all these styles to zero/none, so that you don't see any styles you haven't applied to your page.

If these styles are not "reset", you will see unwanted styles/effects and things breaking. Its generally recommended to "reset" the browser's styles.

Have a look at this article Should you Reset Your CSS?

What's the purpose of using CSS browser reset code?

This is a version of Eric Meyer's CSS reset. You can read about it here:
http://meyerweb.com/eric/thoughts/2011/01/03/reset-revisited/

The goal of a reset stylesheet is to reduce browser inconsistencies in
things like default line heights, margins and font sizes of headings,
and so on.

And here's a history of why and how it came to life: http://sixrevisions.com/css/the-history-of-css-resets/

What exactly does normalization in CSS do?

Normalizing css tries to even out the differences between browsers when rendering html-elements. Many browser have "pre-settings": p and h-elements have vertical margins, lists have some margin and padding too. em and strong tags have bold font-weight.

All this pre-settings are reset, so that you have a consistent working-base in all the browsers.

JSFiddles normalize.css looks like this:

body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,input,textarea,p,blockquote,th,td { 
    margin:0;
    padding:0;
}
table {
    border-collapse:collapse;
    border-spacing:0;
}
fieldset,img { 
    border:0;
}
address,caption,cite,code,dfn,em,strong,th,var {
    font-style:normal;
    font-weight:normal;
}
ol,ul {
    list-style:none;
}
caption,th {
    text-align:left;
}
h1,h2,h3,h4,h5,h6 {
    font-size:100%;
    font-weight:normal;
}
q:before,q:after {
    content:'';
}
abbr,acronym { border:0;}

The sense of normalizing css is debatable, since you have to redeclare every style manually in your stylesheet (even those presettings who make good sense, e.g. a simple font-weight on the em and strong tags which are treated equally by the browsers).

I used Eric Meyer's reset for some time, but stopped using it, since it reset far too many styles which needed redeclaration again. It wasn't worth it IMO.

For a REAL good style-normalizer take a look at the style.css from http://html5boilerplate.com/.

Clarification on purpose of style resets

The purpose of the CSS reset is to help make your page look consistent across all browsers. Here is a very detailed article on the subject by Eric Meyer.

Basically all browsers have different defaults for their CSS presentation, but these defaults are not the same. The CSS reset file attempts to create a consistent baseline across all the browsers.

What is the difference between Normalize.css and Reset CSS?

I work on normalize.css.

The main differences are:

1. Normalize.css preserves useful defaults rather than "unstyling" everything. For example, elements like sup or sub "just work" after including normalize.css (and are actually made more robust) whereas they are visually indistinguishable from normal text after including reset.css. So, normalize.css does not impose a visual starting point (homogeny) upon you. This may not be to everyone's taste. The best thing to do is experiment with both and see which gels with your preferences.

2. Normalize.css corrects some common bugs that are out of scope for reset.css. It has a wider scope than reset.css, and also provides bug fixes for common problems like: display settings for HTML5 elements, the lack of font inheritance by form elements, correcting font-size rendering for pre, SVG overflow in IE9, and the button styling bug in iOS.

3. Normalize.css doesn't clutter your dev tools. A common irritation when using reset.css is the large inheritance chain that is displayed in browser CSS debugging tools. This is not such an issue with normalize.css because of the targeted stylings.

4. Normalize.css is more modular. The project is broken down into relatively independent sections, making it easy for you to potentially remove sections (like the form normalizations) if you know they will never be needed by your website.

5. Normalize.css has better documentation. The normalize.css code is documented inline as well as more comprehensively in the GitHub Wiki. This means you can find out what each line of code is doing, why it was included, what the differences are between browsers, and more easily run your own tests. The project aims to help educate people on how browsers render elements by default, and make it easier for them to be involved in submitting improvements.

I've written in greater detail about this in an article about normalize.css

What are cons of global css reset * { margin: 0; padding: 0; }?

The problem is that there are some elements that need margins and/or padding to display properly, and people forget to set them back. Also, for many elements, you are going to be setting your own styles, overriding the reset, so the reset is redundant; you should instead just set the styles the way you want them.

One problem I see a lot is with lists. If you blindly apply a reset, the bullets for the list will appear outside of the containing element, which always bothers me:

    +--------------------+
    | Some paragraph,    |
    | with text.         |
    |                    |
   *| One                |
   *| Two                |
   *| Three              |
    +--------------------+

Perhaps some designers are deliberately doing this, but I think a lot of the time I see this, it's because someone has blindly applied a reset and not thought about what it would do to the indentation of list items. If you look for this, you will see it all over the place; and pretty much invariably, the site you see it on uses a CSS reset. For more information on how to format lists correctly, see Consistent List Indentation on the Mozilla Developer Center.

Another problem is that after doing a reset, there are sometimes obscure elements that people don't remember to apply margins back to. For instance, the <dl> element; it's default style isn't great, but it at least lets you distinguish between the <dt> and <dd> elements within them. If you apply a reset, you lose that and wind up with everything crammed together with no distinction. Stack Overflow's reset does this, for instance, making <dl> elements pretty much useless:

Term

Definition

Term

Definition

Stack Overflow's reset also lacks any top or bottom margins on the <dl> element, and only a bottom margin to <p>; so I had to add an extra <br> in order to prevent the above <dl> from running up against this paragraph.

If you do use a reset, be very careful to make sure that all HTML elements do display in a sensible way. And remove the parts of your reset that are overridden by later rules that you add; there's no real reason to reset <b> and <i>, and then later apply font-weight and font-style to them, and if you reset a margin to 0 and then set it to 2 em, then why not remove the reset to 0?

all: initial vs. using CSS resets

You are correct that initial resets to initial values for a given CSS property, but note that CSS properties have no initial value for each element-- they only have an initial value for that property, which will be the same for any and all elements it is applied to. For instance, the color property spec has a single initial value defined-- not a list of initial values to which it should be set for every element. So when you use it in conjunction with all, using:

* {
  all: initial
}

...you are telling the browser to take every property of every single element and reset it to the property's default value. So, for instance, the display property spec defines its initial value as inline-- so every single element on your page will be displayed as inline.

Is this CSS Reset okay?

I generally think that wide-ranging CSS resets are not the best. I agree with Russ Weakley, who "zeroed" in on three big concerns:

1. Every element that's reset must be redefined. CSS file size & maintenance can increase.
2. You could forget to restyle something you reset.
3. Some resets are harmful to users who rely on keyboards for navigation.

See his whole presentation here: http://www.maxdesign.com.au/articles/css-reset/

Specifically, I think the following should not be reset, as it is in your stylesheet

:before, :after {
    content: '';
}

:link, :visited, :hover, :active {
    color: inherit;
    color: #000; /* for IE7 'inherit' problem (again) */
    text-decoration: none;
}

:focus {
    outline: 0;
}

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

focus is an accessibility issue.

ol and ul should have their default styles. You are likely to need them. (Although you may need to overwrite them for a nav.)

:link, :visited, :hover, :active I would reset these only as needed.

As mentioned and acknowledged by you *{ // } could cause performance issues and may cause unforeseen issues.

Also, I would consider adding something to reset the big top and bottom margins on headers

h1, h2, h3, h4, h5, h6 {margin-top:0; margin-bottom:0;}

---

Related Topics