Normalize.css: An alternative to CSS resets | Hacker News Reader

Normalize.css: An alternative to CSS resets

necolas.github.com

173 pointsnecolas45 comments

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.

YUI does a really good job with this.

[1]http://developer.yahoo.com/yui/3/cssreset/ [2]http://developer.yahoo.com/yui/3/cssbase/

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...

Thanks in advance.

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

"The normalize.css file is not intended to be a mysterious "black box" that is included in a project and then ignored."

Is there anything that is? I think I'd prefer to use that, if it existed.

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.

[1] http://meyerweb.com/eric/tools/css/reset/

Wellll.... Meyer says right there "In other words, this is a starting point, not a self-contained black box of no-touchiness.".

I understand a lot of people treat it like that, though. I modify the reset to set defaults for each layout myself.

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.

Why? Write your CSS. Test it in browsers. If something doesn't look right, fix it. Resets are bloat.

"Test it in browsers"

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).

> Just normalize elements you want to normalize

In other words, manually do a reset. You can't say reset is unnecessary and then say first thing, just do a reset.

"Manually doing reset" means that you do "reset" only on needed elements (and you target them by id or class).

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.

You'll end up "fixing" the same thing more than once. Not very DRY.

I prefer to know in advance what things are likely to look like. Resets help.

This isn't a reset

* { margin: 0; padding: 0; }

Agreed.

font-size:100.01% is useful, too. http://stackoverflow.com/questions/4541421/is-using-font-siz...

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.

Can anyone explain how this differs at all from resets? The only difference I see on the page is:

> Preserves useful defaults

and I don't know what a "user default" is.

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.

> and I don't know what a "user default" is.

https://github.com/necolas/normalize.css/blob/master/normali...

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.

This appears to normalize everything (make the default css consistent across all browsers) instead of removing the defaults altogether.

It looks like it's just a baseline css file. Many resets and CSS frameworks come with those anyway, e.g. Blueprints typography.css:

http://www.blueprintcss.org/tests/parts/elements.html

"Useful", not "user".

when a user has a different default font and/or size selected in their browser?

Not user defaults, useful defaults.

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.

Yeah, sorry, obviously I can't read. I would like to downvote myself right now.

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.

Any particular reason you linked to your fork instead of the original?

I like that it preserves some normals but either way almost always there will be some overrides so staying with reset.

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.

> Chrome, Firefox 3+, Safari 4+, Opera 10+, Internet Explorer 6+

No version for Chrome?

Since Chrome auto-updates all its users every 6 weeks, specifying the version number isn't necessary most of the time.

And version 1 of Chrome already had most of the things people consider as modern anyway.

Chrome updates so often, even I don't know what version I'm running at the moment. Not that it really matters either.

Looks nice and clean but is github needed for a 3k text file?

(plain text) https://raw.github.com/necolas/normalize.css/master/normaliz...

I don't see why not; it's the goto place for open source code nowadays, no matter how larger or small the project may be.

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.

Reply on news.ycombinator.com