12

For example, the Meyer reset has a long list of elements1 which I believe can be replaced with a *?

I have seen some use of:

* {
   margin: 0;
   padding: 0;
 }

But more "advanced" resets seem to go with explicitly stating the tags.

The only elements I don't see covered in the tag list that are covered (I presume) with a * are input, button, and select—the Eric Meyer reset, in fact, doesn't appear to really deal with those elements at all. If avoiding resetting these elements is the issue…why wouldn't you? Browsers obviously don't all display form elements the same.


1 html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, I, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary, time, mark, audio, video
if you're curious.

Aaron Yodaiken
  • 19,163
  • 32
  • 103
  • 184

3 Answers3

15

You've guessed correctly - the reason is form elements.

If you set border: 0 on for example an input, it will lose the native styling.

For example: http://jsfiddle.net/nrB6N/

And, there's no way to get that default styling back.

thirtydot
  • 224,678
  • 48
  • 389
  • 349
  • (I picked `border: 0` because it's a good example and it's in the CSS reset you mentioned.) – thirtydot Jul 29 '11 at 23:33
  • Thank you for the answer—is there an established reset for form elements that somehow sidesteps this issue? (Perhaps using JavaScript to detect browsers and adjust padding or something accordingly by the native styling? I obviously don't really know what I'm talking about here.) – Aaron Yodaiken Jul 29 '11 at 23:34
  • 1
    In general, you Just Don't Reset Them. Are there any particular inconsistencies you're worried about? – thirtydot Jul 29 '11 at 23:48
  • Yes—I'd like to have the same 'total width' and 'total height' across all browsers, and this is obviously hard with different default border styles etc. – Aaron Yodaiken Jul 29 '11 at 23:53
  • @luxun you could use `:not(button):not(input):not(select)` (* is implied). – Knu Jul 30 '11 at 00:44
8

* is really, REALLY bad for performance (doesn't really matter on small sites, but think the repercussions for 5000+ HTML elements for example). Targetting specific elements is always faster and more efficient. It's a thing to also keep in mind when choosing wether to use an ID or an CLASS. Count in the more than common JavaScript today, and you find out that targetting elements with ID's or precise CSS statements yields in performance improvements.

http://code.google.com/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors

ps. Apart from speed, it also affects input elements, which after the * border, padding, and margin 0 become quite difficult to style so that they look the same accross browsers, especially in IE. Read more: http://www.christianmontoya.com/2007/02/01/css-techniques-i-use-all-the-time/

red
  • 1,980
  • 1
  • 15
  • 26
  • Do you have a source for that? – Aaron Yodaiken Jul 29 '11 at 23:39
  • 2
    Found, and added to my reply. – red Jul 29 '11 at 23:41
  • 1
    If you have 5000+ HTML elements and 4500+ of them are divs then `div` isn't going to be much better performance-wise than `*`. Selectors are generally as slow as the number of elements you have. Otherwise, `*` is just about the fastest possible selector. – BoltClock Apr 03 '14 at 06:46
2

Mainly because its a performance hit. Also, since you do not want to apply reset to all elements all the time but the ones known to cause issues (around box model).

Also, resetting style of select, input may cause undesirable experience.

Mrchief
  • 75,126
  • 20
  • 142
  • 189
  • Could you elaborate a bit here? How does it cause a performance hit (source/tests?) Why don't you want to reset all elements all the time? How does resetting of `select` and `input` cause undesirable experience[s], and what are they? – Aaron Yodaiken Jul 29 '11 at 23:33
  • Being explicit helps you in your favorite browser - IE :). Rest of them are pretty much fine. – Mrchief Jul 29 '11 at 23:35
  • Do you have a source for that? – Aaron Yodaiken Jul 29 '11 at 23:37