Consider change from 'CSS Reset' to 'CSS Normalization'

[necolas]

We should discuss whether or not to move away from using a CSS Reset. An alternative would be to go with some sort of practical CSS "normalization", as @jonathantneal and I been exploring.

https://github.com/jonathantneal/normalize.css
https://github.com/necolas/normalize.css

To get the ball rolling, some of the problems with CSS Resets:

• Many redundant styles.
• Removes many useful defaults.
• Doesn't make it clear which elements and properties actually benefit from some sort of standardisation (i.e. doesn't educate).
• Can have unwanted consequences (e.g. how the the current version of the Meyer reset erases bold and italic font weights from b, strong, em, i.)
• Makes debugging slightly harder in web dev tools because of the large stack of inherited styles.

Previous discussions in the community:

No CSS Reset
Crafting Ourselves
Why “Reset” Style Sheets Are Bad
The Pros And Cons Of CSS Resets

[chuanxshi]

i also noticed that for some very common elements styling (like padding bottom for p tag, and bullet point for ul ) are getting reset, but never standardized under base style. so I feel we should:
a. not to reset certain elements if no clear intention
b. apply base style to things we reset

[anselmh]

very interesting issue… like to see how discussion is going on.

[alanhogan]

It is weird to start a new project and notice your bold text isn’t bold.

[tchalvak]

Compelling, I have issues with css resets for the same reasons. Is there a reason to favor reset over styling?

[alanhogan]

I think the theory is you are forced to choose the values which would otherwise be assumed.

This makes some amount of sense for length-based properties: you may want indentation in lists to be some multiple of your line-height, so why not define it yourself.

The stripping of bold styling off b and strong tags in a reset, however, seems much harder to defend.

On May 14, 2011, at 7:47 PM, [email protected] wrote:

Compelling, I have issues with css resets for the same reasons. Is there a reason to favor reset over styling?

Reply to this email directly or view it on GitHub:
https://github.com/paulirish/html5-boilerplate/issues/500#comment_1164849

[necolas]

Here's an example of a non-reset approach : http://pastie.org/1903258

That file is a quick, rough mix of code from my boilerplate CSS, normalize.css (without the expressions), and H5BP's CSS. It's not much different in length to the existing H5BP style.css file.

Thoughts? Pros/cons? Try using it, does it make your life easier or harder?

@alanhogan The current H5BP CSS should not strip styling off b, strong, i, or em tags anymore. It was the font:inherit declaration in the Meyer reset which did this; now removed.

@shichuan One of the drawbacks of the reset is that it strips useful defaults off of a lot of elements and leaves it up to the author to remember to restyle them. In many cases it would be better to leave the browser defaults in place (or standardise them across browsers). If we were to "apply base style to things we reset", maybe we shouldn't reset them at all.

[stubbornella]

Unless the normalized styles match the developers intentions, the effect will be much the same as a reset. Neither reset nor normalization libs are sacred, they should be edited per project.

[alanhogan]

@stubbornella A good point, to be sure. Hence why length-based settings may not always be a great idea in a generic normalization lib — or at least, not much better than a reset.

That said, if a large number of people would be cool with usable defaults, that’s a timesaver — and what is html5-boilerplate if not {best practice + time-saving}?
On Monday, May 16, 2011 at 12:54 PM, stubbornella wrote:

Unless the normalized styles match the developers intentions, the effect will be much the same as a reset. Neither reset nor normalization libs are sacred, they should be edited per project.

Reply to this email directly or view it on GitHub:
https://github.com/paulirish/html5-boilerplate/issues/500#comment_1181064

[jonathantneal]

@stubbornella, the difference between a reset and a normalization in this particular approach is that most of the normalizer's styles will be kept. For instance, display block for article/section/etc., cross-browser monospace font assignment for pre, niche "odd and done only in one browser"-styling like the unexpected button padding in IE / margins in Chrome, box-sizing defaults that puts every browser at par with the lowest supported IE, as well as extremely common defaults like line wrapping for pre and line height preservation for sub/sup/small inline elements.

Now, when it comes to metrics, margins, sizes, etc. we're thinking of having a separate normalize file that handles these and encourages you to gut it for your own purposes.

[necolas]

At the risk of repeating @jonathantneal's comment: one of the main differences with normalization is that it tackles several common cross-browser inconsistencies (especially in form, table, and pre elements) without erasing the useful browser defaults for specific elements. There is far less redeclaring of styles for elements that are almost always restyled by authors anyway, and no visual homogenization of elements with distinct semantics.

But I do think that a normalization approach should avoid falling into the trap of treating the 'normalizer' like a 'reset', i.e., don't make it yet another black box that is included and then forgotten about. It should be (as best as possible/practical) a transparent part of the CSS that initially brings all browsers into line in some key areas, exposes what styles are doing, and encourages authors to edit and add to the rulesets in order to meet the design requirements of a specific project.

[paulirish]

To satisfy my own curiosity, I compared the size of the H5BP reset and necolas's current normalize.css:

h5bp reset minified: 2025 bytes
normalize minified: 1932 bytes (5% smaller)

h5bp reset min + gzip: 964 bytes
normalize min + gzip: 884 bytes (8% smaller)

[tchalvak]

That doesn't seem appreciable, but then length before additions isn't the best metric, length after is. Not that that's easy to measure. I'll have to try to remember to use the normalized css in my next project.

[paulirish]

It's a rough calculation, btw I basically compared the parts of the reset that mapped to whats going on in normalize... a few things were removed.

But yeah I agree.. for instance you'd still need to set font sizes for your headlines in the reset (though I'd argue you'd need to set them with normalize as well.

I'm eager to use normalize on a new project myself.

[AaronLayton]

I'm going to try normalise with H5BP today and see how it comes out

[necolas]

@AaronLayton If you haven't already started, please could you try using something like this http://pastie.org/2037106

It's a combination of normalize.css and H5BP's CSS. But I've also removed all styles used classes from Modernizr or the conditional HTML classnames (so that there is no penalty or confusion for people who don't use those parts of the project).

If you're using some other combination, please drop it in a pastie or pastebin so we can see that too. Thanks :)

[AaronLayton]

Yeah no problem I will give it a go ;-)

I will probably post some results early next week :-)

On Wed, Jun 8, 2011 at 12:16 PM, necolas <
[email protected]>wrote:

@AaronLayton If you haven't already started, please could you try using
something like this http://pastie.org/2037106

It's a combination of normalize.css and H5BP's CSS. But I've also removed
all styles used classes from Modernizr or the conditional HTML classnames
(so that there is no penalty or confusion for people who don't use those
parts of the project).

If you're using some other combination, please drop it in a pastie or
pastebin so we can see that too. Thanks :)

Reply to this email directly or view it on GitHub:
https://github.com/paulirish/html5-boilerplate/issues/500#comment_1325966

[stereobooster]

i also noticed that for some very common elements styling (like padding bottom for p tag, and bullet point for ul ) are getting reset, but never standardized under base style.

for instance you'd still need to set font sizes for your headlines in the reset

I would prefer to have default sizes for headings, bold font for b and strong, list-style disc for ul (https://gist.github.com/1024831). But @necolas claimed it's must not be placed in normalize.css. So where should we place it?

[necolas]

@stereobooster: @shichuan was talking about the reset in H5BP. Normalize.css makes b and strong bold, leaves default list-styles in place for ul so that nested lists are given different bullets, and doesn't prescribe heading font sizes for the reasons I previously went into. You'll notice that H5BP doesn't set specific heading styles either.

[jonathantneal]

I had intended to break normalize into multiple files, with the base normalize file addressing non-preferential styling fixes and improvements. It was not intended to be touched by the user. Then, I intended to have a separate file addressing popular styling, like normalize.meyer.css for Eric Meyers sizing / colors / fonts defaults, normalize.h5spec.html for the html5 spec's sizing / colors / fonts, etc. I was referring to these secondary files as the "metric" files, which were intended to be touched and manipulated by the developer. You could think of them almost as "themes" for normalize.css.

[ChrisMcKee]

Though in a post IE6 world the need to use a reset is less than it was back in the dark days of having to support IE5.5/6/7 I still 'personally' prefer to have that clean slate; at the same time I've seen the fallout from people blindly using resets without customizing them to their needs or understanding what its doing.

So I'm a tad ambivalent about this shift towards "normalization"; browsers base-style-sheets are setup to provide a consistent browsing experience based on expectations, mostly created over time and mostly ones that have been perpetuated by IE.
For instance, I don't necessarily agree with the argument against strong being reset, not to get into arguing semantics, but surely how you represent that 'strong importance' depends on your UI, strong after all != a font-weight declaration.

The pastie (whats wrong with gist) file looks ok, I suppose the proof is in the eating, and seeing what it breaks :D

[pocketarc]

@ChrisMcKee "'strong importance' depends on your UI, strong after all != a font-weight declaration." BUT. If in more than 50% of the cases it is a font-weight declaration, that makes normalization worthwhile, because less than 50% of the people will actually need to edit that. I'd go as far as saying that the number of people that use font-weight for 'strong' is a lot greater than 50%.

Default should be the ones that -most- people use. That's their purpose. In that sense, normalization seems much better than resets, to me. I mean, imagine 10 websites, and on 9 of those, strong is a plain font-weight:bold. The 10th one is something that the UI calls for, and does not use font-weight:bold. With normalization, you have to edit 1 strong declaration. With a CSS reset, you have to edit 10. It all adds up. :D

[ChrisMcKee]

@BrunoDEBARROS like I said, I don't really want to have a long argument with anyone over semantics, not unless it involves beer anyway. The bit about strong was just an example (and consider it was written at 4am) where the expected behavior doesn't necessarily match the elements described use in its entirety. If <strong> had always been plainly formatted and left to the user it wouldn't have become just another word in many peoples brains for 'making something bold'. The styling is a guess, or an assumption that has been hard coded at the base of browser css for as long as we can remember. That doesn't mean that its wrong to leave these styled, hence i said at the start about people using resets without understanding whats being reset. The meyer-reset does a fine job of resetting everything (as you'd hope), that's the point of it; its then for you to customize and refine these for your own needs.

This boilerplate is much the same; though 90% of it is good stuff, its up to you to carve out the stuff you'll never use and make decisions on what should be added; for me that will in most cases mean ignoring this change and replacing it with my own trimmed down reset. I prefer explicit definition to handing over control to the browser-vendor; I cant say I'm a fan of default margins and padding either, so if I do make use of this normalization I will end up adding the old nasty curative *{margin:0;padding:0;} so I can ensure a certain amount of consistency.

Again its down to preference, but considering this is an option for people I'd prefer to see the change made in a format that means it can be easily stripped out and replaced, and possibly the comparison added to the wiki.

[paulirish]

^_^ just closed with the massive ddaf66a

thanks for all your work on this, nicolas. :) so huge.

all: we're eager to get people trying this out. so.. have some fun!

[tchalvak]

Awesome. will be testing as soon as I can. Heh.