This website is currently being redesigned live! Read more!

« » Start slideshow

Current step: [all]

Latest addition: Sep 26, 2005, 19:17: System of a Down concert


Starting with CSS: revisited

By Faruk Ateş on Jul 26, 2005, 17:11 · 22 comments

Subject level: Beginner

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:

   v2.1, by Faruk Ates -
   Addendum by Robert Nyman - */

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

comments (22)

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

    #1 · By Robert Nyman on Jul 26, 2005, 21:06

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

    #2 · By Faruk Ateş on Jul 26, 2005, 21:55

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

    #3 · By Robert Nyman on Jul 26, 2005, 22:24

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

    #4 · By Sander on Jul 27, 2005, 09:44

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

    #5 · By Matthew Pennell on Jul 27, 2005, 10:05

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

    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.

    #6 · By Faruk Ateş on Jul 27, 2005, 10:35

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

    #7 · By Mike Stenhouse on Jul 29, 2005, 15:13

  8. Mike,

    Nice stuff, thanks :-)

    #8 · By Faruk Ateş on Jul 29, 2005, 15:34

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


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

    #9 · By Scott L Holmes on Jul 30, 2005, 00:13

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

    #10 · By Faruk Ateş on Jul 30, 2005, 02:47

  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.

    #11 · By Scott L Holmes on Jul 30, 2005, 15:11

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

    #12 · By Julian Krause on Aug 5, 2005, 08:09

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

    #13 · By Faruk Ateş on Aug 5, 2005, 08:47

  14. any examples of this in use?

    #14 · By michelle on Aug 26, 2005, 21:04

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

    #15 · By Faruk Ateş on Aug 30, 2005, 12:51

  16. See also Tantek's undohtml.css.

    #16 · By Edward O'Connor on Sep 6, 2005, 23:50

  17. Might it be worth changing the default font-size to 100.01% ?

    Works around some display bugs, explained here and in Listing 16 here

    #17 · By Michael Allan on Sep 7, 2005, 00:26

  18. Brilliant! Thank you for that write-up.

    #18 · By Anton on Sep 7, 2005, 00:56

  19. Michael:
    100.01% seems to be for some versions of Opera - if there's one browser where you really shouldn't support older versions any longer, it's Opera.

    Also, using 100.01% is risky, as it'll interfere with elastic layouts that have em-to-px calculations used for defining (default) widths (such as my newest, upcoming project).

    #19 · By Faruk Ateş on Sep 7, 2005, 01:02

  20. Hey Faruk,

    Long time no speak. I was pointed to this post, and I'd like to ask you to elaborate on how "buttons stop acting like buttons" when using the star selector.

    I've never had this problem before and thus would like some insight on it.

    - Dean

    #20 · By Dean Clatworthy on Sep 7, 2005, 14:16

  21. Dean,

    If you click on a default, square button, it'll invert the bevel and move the text slightly to make it appear as if you've actually pushed it in, pushed it deeper. Using the * selector removes that functionality, and when you then click a button, it'll not look as if you're pushing it in.

    #21 · By Faruk Ateş on Sep 7, 2005, 16:18

  22. First of all, thanks for this stuff, it's great and using on my next site i've started developing in these days!

    I found that if I change the default font-size later in the style for html to i.e. 80%, the table don't inherit the value, so I put the table to the first group in yout CSS, where the html, body, etc. is in, and that solved the problem!

    - Adam

    #22 · By Adam Brunner on Sep 12, 2005, 13:17

Add comment

Basic XHTML allowed (a, abbr, blockquote, cite, code, em, strong)

Additional data

Article overview

You are currently reading Starting with CSS: revisited, posted Jul 26, 2005, 17:11 and filed under CSS, Design.

Log in

Recent Reads

Andy Hume
Switching to Mac OS X
D. Keith Robinson
Web Standards Are Your Responsibility
JavaScript Cheat Sheet (via)
European Digital Rights
Data retention is no solution
Web Standards Project BUZZ
Best Practices for Declaring Languages in HTML and XHTML
Interview with John Gruber
Keigo lizuka
3D Displays (via)
Robert Nyman
Firefox investigation
Flickr - Racism
Racism in news reports
Tim Bray
Mac Mini for Mom

Must-hear Music

Actual Fantasy: Revisited

Suggested Sites

Bloggers I've met
Molly E. Holzschlag
Niels 't Hooft
Didier Hilhorst
Douglas Bowman
Other sites
Dunstan Orchard
What Do I Know
CSS Destroy
Cutting Edge CSS
Design by Fire
Daring Fireball
Jeffrey Veen
Authentic Boredom
CSS Zen Garden
Happy Clog
Anne van Kesteren
Rob Mientjes
Sjors Rijsdam
Jeroen Mulder

More of KuraFire's photos

Valid XHTML and CSS.