Starting with CSS: revisited

« · By Faruk Ateş on Jul 26, 2005 · 41 comments · »

Little over a week ago I posted about my initial.css file, which I have used for a few years now to start off my CSS-powered layouts. Posting about it publicly spurred quite a lot of interest it seemed (the post caused a huge traffic peak that tripled my average), but there were also a few concerns raised by some readers. As a result, I bring you the revised initial.css file.

One of the issues is that my old habit will confuse some people (or at least those that don't notice it and didn't read the comments). I had the following:

html, body {
        font: 80%/130% Verdana, Arial, Helvetica, sans-serif;
}

Having worked with that myself for a few years, I'm used to the text-size being small and dealing with that where necessary, but people new to CSS entirely will not only not have that experience, they may well not quite get why their text is being rendered so small. Bad rule for them to start out with, so that alone was enough reason to revise my initial.css file. There is more, though.

The other thing is the use of the "star-selector," or * { } in CSS. The star selector selects every single element, which produces an overkill of style-nullifying. Sander pointed out that Mozilla (for one) has a great deal of default styling on form controls, which the star selector nullifies when applying margin:0 and padding:0 to it. As a result, buttons don't behave like buttons anymore, and so forth. I never really noticed that, which only goes to show that I'm no longer used to buttons behaving like buttons. I did some research in this, and as it turned out, most of all the weblogs I frequently comment on have this same problem: buttons not behaving like buttons. In most cases, it was indeed the star selector being the culprit.

Additionally, Mozilla developers have stated that the star selector slows down things. While this is apparently not noticeable for end-users in most cases, it may slow down other aspects that interact with the CSS as well. And don't forget that it's definitely a bit overkill to loop through all elements when you only have to alter a dozen of them, roughly.

So, I've come to revise my initial.css file and as a result, I've dropped the star selector entirely in favor of a much safer solution.

The new start:

html, body, form, fieldset {
        margin: 0;
        padding: 0;
        font: 100%/120% Verdana, Arial, Helvetica, sans-serif;
}

Instead of using a star selector, I specified the elements that need to be completely stripped of any default margins and/or paddings. I also specify the renewed font: property here because the html element is targetted. This font styling will now inherit on every element in the page, unless overruled by later styling that you apply yourself. The 100%/120%-bit makes the text behave more like how people new to CSS would expect (or those who switch to using my initial.css in their existing projects).

Then comes the second change:

h1, h2, h3, h4, h5, h6, p, pre,
blockquote, ul, ol, dl, address {
        margin: 1em 0;
        padding: 0;
}

Instead of going through every conceivable element I'm just giving a vertical margin to the elements that greatly benefit from it, then removing any horizontal margin and all padding that may exist.

The rest of the previous file is still fine:

li, dd, blockquote {
        margin-left: 1em;
}
form label {
        cursor: pointer;
}
fieldset {
        border: none;
}

Robert Nyman pointed out that form fields don't inherit all font-specifications as you might expect them to, so for more text-scaling consistency we've added the following:

input, select, textarea {
        font-size: 100%;
}

Here's the new, complete initial.css file that is more safe to work with and has less side-effects that may confuse or annoy you:

/* =INITIAL 
   v2.1, by Faruk Ates - www.kurafire.net
   Addendum by Robert Nyman - www.robertnyman.com */

/* Neutralize styling: 
   Elements we want to clean out entirely: */
html, body, form, fieldset {
        margin: 0;
        padding: 0;
        font: 100%/120% Verdana, Arial, Helvetica, sans-serif;
}

/* Neutralize styling: 
   Elements with a vertical margin: */
h1, h2, h3, h4, h5, h6, p, pre,
blockquote, ul, ol, dl, address {
        margin: 1em 0;
        padding: 0;
}

/* Apply left margin:
   Only to the few elements that need it: */
li, dd, blockquote {
        margin-left: 1em;
}

/* Miscellaneous conveniences: */
form label {
        cursor: pointer;
}
fieldset {
        border: none;
}
input, select, textarea {
        font-size: 100%;
}

For your convenience, you can also simply download the completed initial.css file (right-click / command-click and choose Save Target As).

Bookmark: Newsvine del.icio.us Digg

Comments

41 comments

#1 · Robert Nyman · Jul 26, 2005 (21:06)

First, I appreciate your humble and professional approach when it comes to doing the revising.

However, for me, I usually work in pretty large projects where I don't produce all the HTML (it may be from other web developers, CMS etc). What this means is that I don't know what tags might come up (and there are actually a few of them to choose from).

The only part I do have full control of is the CSS, hence using the * selector to remove margin and padding from every element.

While I do understand the technical aspect of it, I have never experienced any downside to using this when it comes to slowing down the page, halting the rendering and so on. And we're talking on pretty crappy computers as well.

Therefore, I'd be interested in any benchmark tests to see what affect it actually has.

#2 · Faruk Ateş · Jul 26, 2005 (21:55)

Robert,

I believe that the above covers all elements that have any default styling (margin or padding). All other elements simply don't have any, thus there is no need to nullify it.

Also, the form control issue still applies.

#3 · Robert Nyman · Jul 26, 2005 (22:24)

It might cover all elements with that, but a warning bell rings in the back of my head telling me that there's more that do. :-)

Form control is an issue, but it might also be a deliberate design/interaction decision.

#4 · Sander · Jul 27, 2005 (09:44)

All (non-form, non-quirks-mode) default styling in gecko.
Look at forms.css in the same place to see what happens with form-elements.

I don't have time to look at it extensively right now (minutes ticking away in an internet cafe in Cairns here, plus it's much too nice weather outside anyway), so I'll leave the drawing of conclusions up to you.
Other rendering engines do different things of course, but I'd say it's a safe bet that if an element doesn't have any default styling that affects its dimensions in that file (or quirks.css), it won't have any default styling in IE/Opera/Safari/... either. (Cause the bug reports about "my site doesn't look right" would be flooding in with them (or us (mozilla) in the case of IE).)

#5 · Matthew Pennell · Jul 27, 2005 (10:05)

Just a quick comment - that default styling on all the block-level textual elements (headers, paragraphs, etc.) will cause margin collapsing between elements that directly follow each other, such as a series of paragraphs (so instead of a 1em bottom margin and a 1em top margin = 2em, it will just have a 1em gap between elements).

Obviously you're used to it, but it might be confusing for less experienced CSS users.

#6 · Faruk Ateş · Jul 27, 2005 (10:35)

Sander,
Seems like my initial.css is pretty much solid, then. The default margins I specify remove the differences between Mozilla and other browsers, without being all that different from the defaults.

The only thing I hear (just now, from Robert Nyman) is that form controls in IE might have unexpectedly large font-sizes from this. I'll do some testing...

Matthew,
Yep, but that's the same behaviour as browsers do by default: they give a 1em margin on such elements (generally), too.

For all who want to learn more about that, here's a good read on margin collapsing by Andy Budd: No Margin for Error.

#7 · Mike Stenhouse · Jul 29, 2005 (15:13)

I've got a whole bunch of stylesheets I use when I start my projects. initial.css looks like a more toned version of my typo.css sheet but I've got ones I plug in for tables, forms and navigation lists. I wrote it up a little while ago, if you're interested: A CSS Framework.

#8 · Faruk Ateş · Jul 29, 2005 (15:34)

Mike,

Nice stuff, thanks :-)

#9 · Scott L Holmes · Jul 30, 2005 (00:13)

This comes in just in time for a big 'ol project I'm working on.

But from what I'm seeing, all text butts right up to the far left edge - so what's some good techniques for proper margins? Right now I got:

body{ margin-left:.5em; margin-right:.5em; }

tiny margin because my text is all inside a portlet - but you get the idear.

#10 · Faruk Ateş · Jul 30, 2005 (02:47)

Scott,

Generally, a design is either centered or has a specific column on the left side. In both cases, there is no need for a margin on the left on the body element, hence why it's not been added as default styling.

You can apply a margin, a padding, anything you'd like, after the initial.css. It's only meant to neutralize browser differences.

#11 · Scott L Holmes · Jul 30, 2005 (15:11)

Oh, wait. Yes. I got that wrong. I was brain dead when I wrote that (month end financial close!)

Yes. right. I got those margins on the div that makes up the portlet. I left the body alone - thanks.

#12 · Julian Krause · Aug 5, 2005 (08:09)

I just redid my blog stylesheet using initial.css as a base, and it actually removed code from my stylesheet. Thanks for making this. I'm now redesigning every site with this as a base.

#13 · Faruk Ateş · Aug 5, 2005 (08:47)

Glad to have been of help, Julian. :-)

#14 · michelle · Aug 26, 2005 (21:04)

any examples of this in use?

#15 · Faruk Ateş · Aug 30, 2005 (12:51)

Michelle: not yet, as I haven't started on any project since putting the revised initial.css together, but there is one in the pipeline which I'll be announcing soon enough. It's a big one :-)

#16 · Edward O'Connor · Sep 6, 2005 (23:50)

KuraFire Network

Log

Starting with CSS: revisited

Comments

Archives

FlickrFire