4

I was intending to use Eric Meyer's CSS reset but I stumbled in some cross-browser differences (like input margins). Based on it, i came up with a more agressive aproach:

(This is outdated. Don't forget to check the current revised version at the end of this question and criticize it as you wish)

/* CSS Reset by Hugo Leonardo. Based on Eric Meyer's CSS Reset (just google it). */
* {
    margin: 0;
    padding: 0;
    border: 0;
    outline: 0;
    font: inherit;
    text-decoration: none;

    /* in case "font: inherit" fails (IE7) */
    font-family: "times new roman";
    font-size: 100%;
    font-style: normal;
    font-variant: normal;
    font-weight: normal;
    /* remove this block if you DON'T want to support lame browsers */
}

: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;
}

table {
    /* "collapse" here is because of IE7 (maybe others?). don't remove it as it affects other browsers as well */
    border-collapse: collapse;
    border-spacing: 0;
}

/* this entire block was copied from Eric Meyer's CSS reset */
/* HTML5 "display" reset for older browsers */
article, aside, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section {
    display: block;
}

It worked smoothly in all tested browsers:

  • IE7
  • IE8
  • Chrome (newest)
  • Firefox (newest)
  • Opera (newest)

The question is: Does anyone see any trouble here? I consider myself not so good in CSS so I don't know if this will get me in any trouble in the future.

Obs.: this reset is for cross-browser issues only. It should (or must!) be followed by generic rules for elements like input, a, code, and so on (ex: input of type "text" would be invisible without borders!). I will be adding things like generic a styles and stuff later. For now I'm resetting things, getting rid of (almost) everything that isn't the same across the major browsers.

PROBLEMS SPOTTED SO FAR

  • The * selector could cause performance issues.

  • The * selector with some of the rules override some default styles of elements in a way they can't be recovered. ex: the default style of an input of the type "submit".

  • Surprisingly the :before, :after { content: ''; } was breaking select elements in Firefox.

  • In the revised version I tried to set margin: 0 to all input elements. Most browsers ignored it for inputs type checkbox and radio.

REVISED VERSION

/* CSS Reset by Hugo Leonardo Leão Mota
Based on Eric Meyer's CSS Reset: http://meyerweb.com/eric/thoughts/2011/01/03/reset-revisited/
Helped by fellows in stackoverflow: http://stackoverflow.com/questions/6892982/is-this-css-reset-okay */

/* resetting style for every visible element except 'ruby' family and form controls
   browsers deal with controls (and ruby style) in their own way */
a, abbr, acronym, address, b, big, blockquote, body,
br, caption, cite, code, col, colgroup, dd, del, dfn, div,
dl, dt, em, fieldset, form, h1, h2, h3, h4, h5, h6, hr, html, i,
img, ins, kbd, label, legend, li, noscript, object, ol, p, pre, q, samp,
small, span, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, ul, var {
    margin: 0;
    padding: 0;
    border: 0;
    outline: 0;
    font: inherit;
    text-decoration: none;

    /* in case "font: inherit" fails (IE7) */
    font-family: "times new roman";
    font-size: 100%;
    font-style: normal;
    font-variant: normal;
    font-weight: normal;
    /* remove this block if you DON'T want to support lame browsers */
}

/* browsers are free to handle controls but
   we can't let them mess up with the other elements  */
button, select, textarea,
input[type=text], input[type=password], input[type=submit],
input[type=image], input[type=reset], input[type=button], input[type=file] {
    margin: 0;
}



: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;
}

table {
    /* "border-collapse" here is because of IE7 different behaviour (maybe others?).
       don't remove it as it affects other browsers as well */
    border-collapse: collapse;
    border-spacing: 0;
}

/* the next two blocks were copied from Eric Meyer's CSS reset */

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

/* HTML5 "display" reset for older browsers */
article, aside, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section {
    display: block;
}

END

Well, the more i tried to improve my reset, the more it looked like meyer's css reset, so i gave mine up and adopted it. works just fine :p

Hugo Mota
  • 11,200
  • 9
  • 42
  • 60

4 Answers4

6

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;}

Jason Gennaro
  • 34,535
  • 8
  • 65
  • 86
  • Well, it's a great answer. Although a big part of it is covered by my **Obs**. That's not the end of my file, it's only for resetting differences from the browsers. **I do intend to create a lot of generic rules after that**. Why is `focus` an acessibility issue? About the heading margins, they are already covered in the first selector. I'm posting a new version right now if you want to criticize more. I really apreciate that (no kidding) (: – Hugo Mota Aug 01 '11 at 03:15
  • 1
    Thanks @hugo_leonardo! Gotcha about more generic styles coming. `focus` is an accessibility issue because if you tab through a form, you will have a more difficult time discerning where you are without the outline. I added the bit about the headers because I strongly suggest you get rid of `*{ }` and the bit about headers is one thing I think you could add. – Jason Gennaro Aug 01 '11 at 03:22
  • Well, i'm just trying to get rid of everything that is not the same in all browsers. Since not every browser adds the `focus` style to their inputs, i'll just do it by myself later. As you can see in the revised version, i got rid of the `*` selector (it was reeeally evil). Let me know if you spot something else wrong (: – Hugo Mota Aug 01 '11 at 03:31
4

This is using * which will affect everything. You can't get borders for input, select etc. back in with a "later" stylesheet.

Also, * is considered bad for performance. Using explicit tags is preferred.

Try html5boilerplate's reset if you're having issues with Eric's (not sure if it will solve them, but worth a shot)

Mrchief
  • 75,126
  • 20
  • 142
  • 189
  • 3
    Why not? Why wouldn't `input {border:1px solid black;}` or `html input {border:1px solid black;}` do it? – Richard JP Le Guen Jul 31 '11 at 23:24
  • That's not the same. I (my OS) can have different styles or even my own custom styles defined. – Mrchief Jul 31 '11 at 23:26
  • Since it's a generic selector it can easily be overriden. And it will be (see the 'obs'). And the whole point of a CSS reset is to remove these predefined styles! About the performance, is it a relevant difference? Because the prize sounds worth to me. – Hugo Mota Jul 31 '11 at 23:32
  • 2
    @Richard JP Le Guen: [This](http://jsfiddle.net/nrB6N/) is what this answer is referring to ([from here](http://stackoverflow.com/questions/6880002/why-dont-css-resets-use-to-cover-all-elements/6880025#6880025)). Removing the native styling for form elements in a way that can't be undone is not good. The performance aspect of `*` is mostly irrelevant. – thirtydot Jul 31 '11 at 23:40
  • now it makes sense...i'll review it taking that into consideration (: – Hugo Mota Jul 31 '11 at 23:43
  • @thirtydot: Thanks for pointing that out. I wanted to include that link but didn't have the time. I wish I could upvote you again on that one! – Mrchief Aug 01 '11 at 01:10
  • @hugo: The perforamnce difference may not be noticeable to the eye (it'll be in milliseconds _almost_ _always_) but it'll make an impact with time as your app grows (and again, IE 6/7 will be hit mostly). However, the broken styles would be a bigger problem. – Mrchief Aug 01 '11 at 01:13
1

My only concern is the performance issue caused by using the * selector

Ahmad Alfy
  • 13,107
  • 6
  • 65
  • 99
0

I dont see any trouble with it, if you've tested it and it works then it should be fine.

Aaron Lee
  • 1,146
  • 3
  • 14
  • 29
  • 9
    I think it's important to remember that a lot of issues can be solved with "if it works, then it should be fine" - that's the wrong way to look at programming. It needs to not only work, but also scale properly, and planned appropriately to avoid future issues (that you aware of yet). – Garrett Smallwood Jul 31 '11 at 23:51