Philosophically, I think I prefer this approach to resetting everything.
I'm not sure, however, I'm on board with the idea that you tweak this for every project you work. That would make merging future evolutions of these styles (e.g. when new browser versions are released) a real pain.
It's also a bit disconcerting that the project authors went their separate ways and there are now two projects? Hm.
We both collaborate on this repo and much of it was pulled into Jonathan's original repo (which also contains some of his personal preferences and an additional metrics file).
Different people forking it for their own preferences is one thing, but not having a canonical resource for the project is -- well, like I said, disconcerting. But maybe it's just me.
Don't mean for this minor nitpick to overshadow the rest of the work you guys have put into this, by the way. It's good stuff.
I think a combination of CSS reset[1] and CSS base[2] is the best way to go. Use CSS reset to remove all styles, and then use a standard CSS base to set a new set of defaults. That way you can easily distinguish between what styles are used for resetting, and which are actually meant for styling.
Random question: I was looking at [1], linked by Normalize. How come the element HTML element "A" has no default values? It sure seems to always be blue/purple and underlined...
I think this was in referrence to adding "reset.css"[1] as your first css file. It is very "black box," as it is something that you add but never modify.
If you need to minimize it, run it thru Sass as the final step before publication. Sass will blackbox the living hell out of it. But, you know, in a way that makes sense.
That's the reason for resets. Because "browsers" could mean one of a million different browsers and it would take forever to tweak each of them, since CSS isn't the same across the board. I'd like to see some CSS that isn't using a reset that looks perfect across IE 6, 7, 8, 9, Opera X-Z, Chrome X-Z, Firefox X-Z, and Safari. Additionally, I'm guessing such CSS could probably be done faster with a reset.
Any competently written CSS will give you that without the resets and normalizers nonsense. Just normalize elements you want to normalize, without polluting your inheritance chain and making yourself pain to debug it.
I've been writing CSS for god-knows-how-many years and never ever saw the need for it. And yes, I do cross-browser sites (and that even includes Opera).
That's just too much manual work that's the same over and over again. We already know what elements are different between browsers, and reset fixes that, without requiring manual labor; it's a better approach.
Not sure who those "we" are, but reseting every damn element is far from demonstrating knowledge. Especially if it is separate stylesheet. There is nothing better in that approach at all.
Maybe if you have absolute control over the HTML that's ending up inside your pages. Mostly I work on sites where someone's going to be using a WYSIWIG or raw HTML to add content, and I have no control over what elements they use or which browsers they test in.
CSS gets re-written anyway along the way. Resets gives you a leg up in the beginning for a consistent look across browsers so you can focus on other pieces of a project -- at least that's how I use it.
Awesome approach. Whenever I start out a project, I always reset, then normalize it back up to a common standard, then apply the additional style. It's good to accelerate the first two steps with this.
Traditional resets require the CSS author to build styles for every element back up from nothing, or to remove the corresponding rules from the reset. In practice, you get into the situation where the designer doesn't encounter all those tags on a limited mockup page. Then when it comes time to build out the site, and the developer or author tries to format a list, or emphasize text with a <strong> element, neither has any effect at all. When it comes to visual style, any element not explicitly allowed by the CSS designer is denied.
<strong> elements should generally show some kind of emphasis, probably boldface, but a full CSS reset sets them back to plain text. If all you've gained from the full reset is the opportunity to forget to set them back to boldface, what was the point?
This project looks like an attempt to retain the most useful properties of a CSS reset (like consistent default element margins) while forestalling the process of redefining each element piecemeal to look pretty much like what the browser would have shown in the first place.
There's nothing earth shattering, but some things have non-zero margins, sub/sup have offsets, etc. CSS resets basically strip all default formatting, while this strips most of it.
Some css resets strip out bullet styles for lists, or focus styles on selected text boxes. I assume this keeps things like that intact instead of nuking everything.
This is very similar to what I've been doing since 2008 with http://sencss.kilianvalkhof.com, except I also provide a good vertical rhythmn. I should probably start promoting it more again ;)
That said, the form stuff in normalise.css takes a very different approach that I'm definitely gonna try out.
They've taken some liberties in correcting (arguable) flaws in standard stylesheets, ex. setting cursor:pointer on form buttons, but I like all that they've chosen to include. Never been a fan of full reset stylesheets, but there's a really good chance I'll take advantage of this, and the research they put in, for future projects.
Looking through it I don't see it as a replacement for reset except in a few cases. In particular, most of the stuff in there (great documentation, btw) seems to be oriented toward fixing strange browser quirks not covered by reset. For example, things like "Remove Android and iOS tap highlight color [from html-tag] to prevent entire container being highlighted..." Seems like a very natural add-on to reset to me.
Github makes it easier to track projects without having to download 3kb files only to forget about them several days later... And of course, there is the Git part.
I'm not sure, however, I'm on board with the idea that you tweak this for every project you work. That would make merging future evolutions of these styles (e.g. when new browser versions are released) a real pain.
It's also a bit disconcerting that the project authors went their separate ways and there are now two projects? Hm.