Is there a Github repository for this somewhere? I couldn’t find anything. If not would you mind throwing this on Github? Would make forking it and iterating on it a lot easier.

–Max

I’m not trying to be rude but my guess is that you didn’t actually test this. My point was this…

“Firefox is setting the line-height to normal on buttons and is enforcing this decision with an !important declaration.”

http://www.cssnewbie.com/input-button-line-height-bug/

“user !important rules override author !important rules.”

http://www.w3.org/TR/CSS2/cascade.html#important-rules

My guess is that you didn’t look at the latest version which contains these two additions:

* Changes in this version:
– input, button, textarea, select, optgroup, option {line-height: 1.4 !important;} (to override FF’s default styling)

* – styling inside (merci Goulven)

I believe Firefox obeys that rule though (at least it should according to spec).

However, I have found that your attempt to over-ride FF default line-height on form elements (specifically buttons) is, unfortunately, wishful thinking. The default FF stylesheet defines line height for buttons using: normal !important and, at least in my experiments, cannot be over-ridden. This makes sense for things like select, I suppose, but why they decided to include button makes no sense to me.

As that doc says, this is a current UA practice, so I’d say using such styling goes against the idea of this article which aims at:
1. avoiding redundancy,
2. setting explicit styles rather than resetting values.

PS: Thanks for the kind words.

Any thoughts on the w3.org css default styles then, how it compares to your styles or if it creates any problems your styles fix overall. Just curious, it’s made a pretty decent base stylesheet starter kit.

thanks,
T.

Cheers! :-)

Anyways, those who want the “badge” can either drop these fixes or use Conditional Comments to hide the “CSS filters” I use for IE 6 and 7.

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Ftjkdesign.com%2Fez-css%2Fcss%2Fbase.css&profile=css21&usermedium=all&warning=1&lang=en

“This is not much difference from…”

I think being explicit here is what matters. It allows authors starting with these rules to simply remove whatever they don’t need. And there are many they could remove…
For example, I often leave form and table elements out of the styles sheet as I usually only include this styling in the HEAD of documents that contain form and table markup.
It’d be the same for pre, code, dl/dd/dt, etc. It really depends on the common markup used across the site.

“What is wrong with default margins…”

I think your test cases demonstrate pretty well what’s wrong ;)
My own “conclusions” are a bit different than yours though. For example, in your test 2d you say IE is wrong “because this should only appear if there was a padding or a border”. I believe it would appear the same if the container was a block formatting context, and isn’t what hasLayout does in IE? hasLayout creates block formatting contexts, hence it will prevent collapsing margins. In short, I’d say this is expected behavior, it’s not really a bug.

For 4a & 4b, I see something different. You say “The container has hasLayout and this causes the paragraphs’ and headings’ vertical margins of ‘auto’ not to resolve to ’0′ and are contained by the containers’ content/padding edge”. I do not see padding playing a role in there. In these cases, I believe IE simply *ignores* the (auto) declarations and defaults to default margin values. And because those containers have a layout the margins of these elements do not collapse.

“BTW, your base CSS is larger than my non IE7- CSS…”

That’s great!

Thanks for linking to your test cases.

I see that you have.

body, p, dl, dt, dd, ul, ol, li, h1, h2, h3, h4, h5, h6, pre, code, form, fieldset, legend, input, button, textarea, blockquote, th, td {
margin: 0;
padding: 0;
}

This is not much difference from.

* {
margin: 0;
padding: 0;
}

What is wrong with default margins,

http://css-class.com/test/css/defaults/default-margins.htm

and controlling margin collapse with ‘auto’.

http://css-class.com/test/bugs/ie/haslayout-margins.htm

Ask yourself if you would use a reset.css or base.css file if there was no browser named IE7 or IE6?

BTW, your base CSS is larger than my non IE7- CSS.

http://css-class.com/test/zeta-0-1.css

You should find plenty of good info about font-size here:
http://css-discuss.incutio.com/wiki/Font_Size

This one explains the rational behind 100.01%:
http://www.communitymx.com/content/article.cfm?page=5&cid=FAF76

fwiw, as I said in my reply to Jorge, I do not set font-size on body

Thanks

As you say, this rule is to reset padding on elements in DDs, LIs, and fieldsets.

If I decided to leave all headings out, it is simply because I rarely include them in those elements (never in DDs I believe) and when I do (in LIs for example) it almost always calls for custom styling anyway…

In any case, people who are used to this type of nesting should definitely include headings in there (may be not the h1 though).

I think the idea is to not over do it. For example, people who use a single h1 per document may want to remove this selector from the base rules if they are already “custom-styling” it somewhere else in the styles sheet.

In short, we want to avoid redundancy and we do not want to create rules that don’t really style anything across the documents.

when there is a H1,H2… tag is nested, then it is indented relative to a paragraph beneath it.

Because if I have

Heading
some text

Because if I have

Heading
some text

Thanks for a great post. A good read and lots of knowledge from you and the discussion here. I had been using a plain reset and never occurred to me to cut out the middle man, you did a good job with this base style sheet I am starting a new project today and will be using something like this now. :)

Question though I am having a tough time understanding the font sizing. I had been setting a base font size of 62.5% in my reset and then sizing with em’s inside. What is the best way to accomplish that now? I do not understand the 100.1% part.

Thanks again!

-Ryan

As the base styles sheet shows, I do not set font-size on html nor body.
If I need to reduce default font-size across the board, then I use em on the main wrapper.

And I’ll add the fix for monospace too:
http://meyerweb.com/eric/thoughts/2010/02/12/fixed-monospace-sizing/

Thanks

You need to replace ol li {/*styles…*/} with ol li, ul ol li {/*styles…*/} so that the UL rule doesn’t apply blindly to OL inside UL.

Thanks for this! It’s my first project trying this style sheet :-)

If you are supplying your client with a CMS, there really are only a handful of tags they will be able to use anyway, so there’s no point going over the top and resetting everything.

I would want tags to display in some tailored form, even if I hadn’t added CSS for them. So, for instance, if I hadn’t restyled a list item and someone used it on the site, it would be better to display as the default browser list item, than to have no margin, padding, or bullets because I’d reset everything.

I only mention that because when I first started using the ‘donkey reset’ ( *{margin:0;padding:0} ) I had some growing pains because I was used to inputs with padding, etc. Then when I switched over to the YUI reset, I had a bit more of the same.

Switching back will cause this all over again, but like I said, I definitely understand where you’re coming from, and what better time to get started, right?