
Should You Reset Your CSS? - kingsidharth
http://sixrevisions.com/css/should-you-reset-your-css/
======
cheald
I've landed solidly in "always reset" territory. There are just so many
inconsistencies between browsers/platforms that I'd rather have everything
looking as consistent as possible, and work from there. It does add extra
garbage to Firebug, but it's worth not having to debug a display issue on a
browser on a platform that I don't have access to.

~~~
pornel
Browser stylesheets are well-known, default styles testable, and yet most
resets still nuke _everything_ "just in case".

[http://css-class.com/test/css/defaults/UA-style-sheet-defaul...](http://css-
class.com/test/css/defaults/UA-style-sheet-defaults.htm)

There are only few differences that could break layout.

Hard problems are caused by different _interpretation_ of applied styles, not
because of defaults.

In case of form elements (which are underspecified in CSS), touching their
style can make inconsistencies worse (different browsers use different box
model for form elements, and achieve similar size with browser-specific
defaults).

~~~
nitrogen
My biggest gripe with form elements is when sites (and browsers) expect the
default to be black text on a white background, and change the foreground text
to a near-black color. This wreaks havoc on systems with a dark colorscheme,
where system input boxes have white text on a black background. This is the
sole reason why I no longer use light-on-dark colorschemes, which I find much
more pleasing, on my desktop (and laptop).

------
greghines
I avoid CSS resets because it makes it more difficult to work with the styles
in Firebug. Because most resets apply to every element, if you've selected an
element five levels deep, you're going to see five copies of the reset in the
style list. And if that element is inheriting from other non-reset styles up
the tree, they're going to be buried in the middle of those extraneous copies
of the reset. That's a lot of noise added to what should be a simple,
straightforward list of the styles that apply to the element you've selected.

------
Pewpewarrows
I use Richard Clark's CSS Reset paired with my custom-built scaffolding CSS
stylesheet. It rips out all the base styles applied by browsers, and builds
them back up so that absolutely everything: fonts, form elements, tables, code
blocks, etc not only all look identical in every browser, but are easy on the
eyes.

I find it pretty laughable that developers ignore Resets because of a little
extra noise in their CSS debuggers. That's like advocating against using a
framework for another language because your stack traces are a little longer
by default. In Chrome's Dev Tools you can hover over any final computed style
to determine exactly what file and line it came from, and the rules are shown
most-specific first. I rarely if ever have to scroll down to the broader rules
where the duplicated Reset noise tends to be more prominent. I haven't used
Firebug in a year or two, but I'm assuming it has similar developer-friendly
functionality.

~~~
lukeschlather
It seems more like those who categorically argue you should avoid frameworks,
because hand-crafted code is going to be faster.

Which is about the only concrete benefit I see to avoiding resets. I'm
probably going to tweak about the same number of properties, and the defaults
are saner.

------
mikeryan
My personal technique is to start with a slightly simplified version of
Meyer's reset. Then as I get to final QA I comment out each reset selector and
see what happens.

It kind of gives me a happy place between using them and not.

------
akamaka
I don't use pre-built resets, partly because they didn't exist when I started
doing web development, but mostly because I'm not pursuing "pixel perfection".
Ironing out tiny cross-browser issues is the very last step for me, after
having dealt with content, usability, accessibility, maintainability, and
performance.

------
juddlyon
There are good arguments for both but I've tended to agree with Yahoo's
approach to YUI, which includes a reset. Not because I've explored it in
detail, but because I figure Y! has (and at a large scale).

------
schammy
The second I learned this trick, many years ago, I've used it in everything.
The argument that it's "slow" is ridiculous. It's like using while(i--)
instead of a for() to shave 0.0000001 milliseconds off your javascript loops.
Just admit you have OCD and move on ;)

~~~
Locke1689
I'm fairly disinclined to trust web designers on browser rendering performance
issues anyway. If it were that big a deal it would be in CSS optimization code
somewhere, but it clearly isn't.

