Is a CSS Reset Still Necessary

Is a CSS reset still necessary?

yes, the same reasons they were created still exist: several browsers have several different implementations of CSS, and this is one way to take care of them.

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?

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.

What are the advantages of using a reset style sheet instead of all:unset?

Using all: unset revert all the styling to its initial value or inherent value. and the initial values sometimes are not like the user-agent one that every browser defines differently (one example is that the initial value for display is inline and not block). using "Normalize" builds and reverts the styles on top of the user-agent defaults.

in the future you could use all: revert that revert to the user-agent styling.

Should my css reset go before or after my css code?

CSS prioritizes as it progresses, as well as by a scoring method that can be reviewed in Toni's comment: http://coding.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/

You would do your reset first, then override your styles as you progress in the stylesheet. Consider the rules in that link to fully understand how css will score the selectors.

Also, Sadaj has a good suggestion as well.

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

---

Related Topics