About normalize.css: a modern, HTML5-ready alternative to CSS resets
nicolasgallagher.com
nicolasgallagher.com
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.
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.
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.
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 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.
I do! But it's using and customising only the parts that are needed (...and a few lines of CSS are a bit old and out-of-date).
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 reset IE to 100%, and retaken the screen cap. I still see differences. take a look:
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 ...?
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
@import 'normalize.css/html5-fixes.css'
@import 'normalize.css/html5-defaults.css'That said, a reset file is always a good idea, and this is a nice evolution thereof.
Why not? It's being updated regularly: https://github.com/necolas/normalize.css/commits/master
The last thing I would want is the behaviour of my css changing periodically.