One of the big things I like about CSS resets is it forces me to think about every design decision rather than just going with the 'sensible' browser defaults.
I guess with discipline I can train myself to always think about things like the rhythm created by font-size and margins on headers, but I've not experienced the downsides of a full reset yet.
As far as downsides of a full reset, I dislike the way my inspect panels are cluttered with reset information for each element. Having switched to normalize a few months ago, inspection tools now hold only the relevant CSS rules for the item I'm inspecting.
And I'm not sure why a CSS reset would make you consider each design decision; most design work should be done prior to coding, and its a rare instance that I don't replace most defaults.
I agree. Maybe I'm missing the point, but I loathe default stylings. Ugly grey buttons and annoying blue html links normalized across browsers are still ugly grey buttons and annoying blue html links.
The point of normalize, at least how I use it and understand it, is if you wanted to change a default style you just go into the normalize.css file and change the style of links, or buttons in there, and be assured they work cross browser.
As apposed to having to to declare a reset, and then re-declaring everything again.
He says this in the article too:
"Approach 1: use normalize.css as a starting point for your own project’s base CSS, customising the values to match the design’s requirements."
The point of normalize is not to keep links blue, and buttons gray. They find the rendering discrepancies between browsers, fix them, and make it easy for you to change.
agreed. But "forcing me to think" sounds like a lot of work, I would argue resets are less work.
normalizations are all about memorization, ie default for h1 is A h3 B. To me this is far more complicated than deciding i want X, what do i need to do to produce that. maybe a little extra typing, (probably a trivial amount for a website or web app of any complexity).
I use it indirectly (via Twitter Bootstrap) and I have no complaints.
I found it a bit curious though that they don't dogfood it on their Github page (http://necolas.github.com/normalize.css/), but I guess that's not a huge deal or anything.
Perhaps I am missing something here. I looked at the demo page in FF10, Chrome17, and IE 8, and I see different spacing in rendering across those platforms (mostly in IE8, but FF10 and Chrome17 are not the same either)
Resets attempt to make a site look the same in all browsers by resetting them all to the same starting point. They give you a blank canvas.
Alternatively, Normalize attempts to make all browsers behave how you'd expect by resetting their inconsistencies, but it doesn't bother trying to make them all look the same. It just gives you a predictable canvas.
I have been using normalize for the past few months in all of my new projects and I can attest to its superiority over the standard resets. Great work, as ever, necolas.
Doesn't this mean that you have to address the specifics of each browser that might use your site though?
So if Konqueror 3.42 [made up version] has a bug giving a default of double the normal padding on h1 then I have to specifically check that this is addressed by the attempted normalization.
>"Normalize.css is an alternative to CSS resets. The project is the product of 100′s of hours of extensive research by @necolas and @jon_neal on the differences between default browser styles."
Makes me think that I'm going to need to update every site using this with every new browser version that has a pixel difference in it's default style; a situation that a reset just works on.
Of course resets are subject to browser bugs too but it seems that they are more robust and more likely to just work ...?
Not really. The outcome with normalize.css is as splendid as with the reset bull-doze approach. The advantage of normalize however, is that size of your stylesheet is much smaller.
And probably you'll be more aware about vendor treatment of different properties. Unlike with include-and-forget (lazy-bum) approach of reset.
That is a strong claim given that the "modularisation" is realised adding banner comments in the CSS. I think it would had been better to have separate @import'ed files. Those worried about performance could use minificators while other, like me, could just use the parts they are interested in, in my case
Its not silly at all. It keeps version history and people can easily share their changes, and github provides an easily accessible place to download the file from. What would be a better place to share this file?
I guess with discipline I can train myself to always think about things like the rhythm created by font-size and margins on headers, but I've not experienced the downsides of a full reset yet.