The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Since I've begun using my fieldsets more, I don't have fieldset border set to none anymore. If the page has a lot of actually bulletted lists, instead of menus, I don't have the last delcaration either.

If there are a lot of forms (something other than username/password, or search) then I modify the padding. I hate doing it, but somewhere there's some magical problem with padding and forms-- I've never heard explicitly what the problem actually is, just "something to do with accessibility" that I can't find with JAWS, so in this case, one the site with the 100 forms:

Meaning it's different per page, since I will not list elements who are not in use in my reset. I still remove padding etc from form elements, just not the inputs, which is apparently where the problem is. Since the inputs are inline, I'm 99% sure that the "accessibility" problem has nothing to do with margins, but only padding. So I can still zero my margins.

I like the control of setting margins and padding where I need them, and know that wherever I say nothing, the amount there is ZERO. This is so incredibly useful, especially when stlying lists-- you just can't beat that "IE uses margin and FF uses padding" (or is it the other way around?) with CSS. You need to start at zero, or lose your bullets or images or whatever--choose which browser will look like garbage. That's not a choice I will make.

I know some people would think it's a good idea to have a slightly bloated CSS reset sitting somewhere, and letting every page reference to it. But it seems much easier to me to just taylor the code to the page-- I'd rather have each page or site optimised rather than use bloat to make things flexible or easier for the developer. Why make the client download all that garbage if it's not needed?

You are a good coder and know your stuff. I have been looking at your site. Keep up the good work. Lets put our minds together and come up with an even better reset.css. I see from yours and mine combined that we could complete the missing pieces

Thanks, but I'll be the first the first to admit, I still have a lot to learn!

Originally Posted by cooper.semantics

Also, I would omit your stylesheet from using outline: 0;

.inline, .floatleft, .floatright I would get rid of.

Morning,

Well as long as you give a :focus style then outline: 0; is fine. Ya I don't really use those classes. Those are more or less for the people out there that like using classes for things - just good ones to have in your pocket. I usually target all my elements like this

As a clearing method I really like it! But whats the -9999em for? And why the zoom? I know what it does - but is it necessary? And it can also be trimmed. You'd only be using the <br> for that - so you can do away with the class of .br. But I like it. No one uses the <br> anymore so it's perfect for this. Plus there's no closing tag with in the html. So essentially you just have to put a <br> as a clear. Verses <div class="clear></div>. I don't know - this might give <br> an actual use again. So I'd do it like this!

Just a thought? Isn't only nessesary in a css reset to remove margin and padding on block level elements? If that's the case, then Eric Meyer's resets can and should be trimmed.

Also, one of the reasons most people don't just say *{margin:0;padding:0;} is becuase it's heavy on browser resources to have to constantly be removing everything from every element. So, from what I've read, the consencious is that it's better to just reset element by element.

Since I've begun using my fieldsets more, I don't have fieldset border set to none anymore. If the page has a lot of actually bulletted lists, instead of menus, I don't have the last delcaration either.

If there are a lot of forms (something other than username/password, or search) then I modify the padding. I hate doing it, but somewhere there's some magical problem with padding and forms-- I've never heard explicitly what the problem actually is, just "something to do with accessibility" that I can't find with JAWS, so in this case, one the site with the 100 forms:

Meaning it's different per page, since I will not list elements who are not in use in my reset. I still remove padding etc from form elements, just not the inputs, which is apparently where the problem is. Since the inputs are inline, I'm 99% sure that the "accessibility" problem has nothing to do with margins, but only padding. So I can still zero my margins.

I like the control of setting margins and padding where I need them, and know that wherever I say nothing, the amount there is ZERO. This is so incredibly useful, especially when stlying lists-- you just can't beat that "IE uses margin and FF uses padding" (or is it the other way around?) with CSS. You need to start at zero, or lose your bullets or images or whatever--choose which browser will look like garbage. That's not a choice I will make.

I know some people would think it's a good idea to have a slightly bloated CSS reset sitting somewhere, and letting every page reference to it. But it seems much easier to me to just taylor the code to the page-- I'd rather have each page or site optimised rather than use bloat to make things flexible or easier for the developer. Why make the client download all that garbage if it's not needed?

My two eurocents : )

I agree with your viewpoints. I think a reset.css depends on exactly how big of a project your on at the time. For a smaller project you could get away with bare minimal styles. With a larger project a bulkier reset.css becomes the case.

Think of it like this: 50 page site.
It would be a pain building/debugging if your reinventing the wheel for pretty much every 5 pages :-D

If you are re-inventing the wheel on every page it probably indicates an implementation flaw. As long as your stylesheets are well organised and encapsulated, you simply don't need bloated default styles on every page.

If you are re-inventing the wheel on every page it probably indicates an implementation flaw. As long as your stylesheets are well organised and encapsulated, you simply don't need bloated default styles on every page.

Exactly, that is why there is a reset.css

What I like to do is:
If there are 10 pages tied to the about section I will have an about_common.css.

Just a thought? Isn't only nessesary in a css reset to remove margin and padding on block level elements? If that's the case, then Eric Meyer's resets can and should be trimmed.

Also, one of the reasons most people don't just say *{margin:0;padding:0;} is becuase it's heavy on browser resources to have to constantly be removing everything from every element. So, from what I've read, the consencious is that it's better to just reset element by element.

What I like to do is:
If there are 10 pages tied to the about section I will have an about_common.css.

This will set common styles for the about section.

That is what I'm getting at. Modularisation is far better (imo) than huge catch-all style sheets. It's more extensible, adaptable and convenient for debugging purposes as you can immediately isolate certain components.

I would leave certain form elements alone from your reset techniques as if you change borders or padding you can kill their default look and behaviour straight away. This was cited as the main reason for moving away from *{margin:0;padding:0} and moving to a more spohisticated set of reset rules.

I wrote an article years ago which explain what happens to form elements when you start removing padding etc and was about the same time that the reset techniques started popping up. Once the behaviour is removed (such as the depress effect of submit buttons when padding is removed in mozilla) the behaviour can't be re-instated.

I use a smaller version of Eric Meyer's reset but I don''t see the usefulness of removing bold from headings and other elements that everyone expects to be bold as i have to spend my time re-applying bold to them all again which creates more work than if I had to remove it when needed.

I wouldn't use a break as a clearer because there are better methods available such as the clearfix method or the "overflow" method.

I think reset stylesheets are a good idea especially for beginners that don't realise that they should be in control. However, I do find that 50&#37; of the reset is redundant on a day to day basis and I'm coding different sites every day.

However, snippets of code are always useful and if you build a reliable code base that you can cut and paste from project to project then that's a good thing

I would leave certain form elements alone from your reset techniques as if you change borders or padding you can kill their default look and behaviour straight away. This was cited as the main reason for moving away from *{margin:0;padding:0} and moving to a more spohisticated set of reset rules.

I wrote an article years ago which explain what happens to form elements when you start removing padding etc and was about the same time that the reset techniques started popping up. Once the behaviour is removed (such as the depress effect of submit buttons when padding is removed in mozilla) the behaviour can't be re-instated.

I use a smaller version of Eric Meyer's reset but I don''t see the usefulness of removing bold from headings and other elements that everyone expects to be bold as i have to spend my time re-applying bold to them all again which creates more work than if I had to remove it when needed.

I wouldn't use a break as a clearer because there are better methods available such as the clearfix method or the "overflow" method.

I think reset stylesheets are a good idea especially for beginners that don't realise that they should be in control. However, I do find that 50% of the reset is redundant on a day to day basis and I'm coding different sites every day.

However, snippets of code are always useful and if you build a reliable code base that you can cut and paste from project to project then that's a good thing

Yeah I agree. Headers should prob. be left with there default font-weight.
For clearing I personally think that the clearfix is probably the best I have seen so far. The float to float method is not fun debugging

Also, overflow fixes are not that fun either because you never know when you are going to have an overlay pop-up via JScript. It clips anything outside it's walls.

I saw your reset and think its a cleaner version of Eric Meyers. Its minimal and gets the job done

Personally I agree with the people using the universal selector for things like margin and padding.

I don't see why some have a whacking great list of tags for this? Surely:

Code:

* {
margin: 0;
padding: 0;
}

is much less cluttered!

Think about what you are doing. I am guilty myself of zeroing out all elements!
Say you have a paragraph and its now set to zero - You will have to define paragraphs for the rest of your site. Your probably thinking well I can define a paragraph in the reset also but, even so you could also define other tag elements. So that just proves that using a wild card to zero out all elements is useless. You will learn a lot of new things from this thread. I have!!!!

It's still a work in progress, but I'm pretty happy with mine! Although after looking over Eric's resets I may add a thing or two to it. But his are a little overkill for my taste as well. Also, primarily because of all of our long discussion on relative font sizes, I'll probably end up changing my 62.5% on the body (because of the associated nesting issues) to 81.25% and therefore the typography section will change a little bit also. I'll give it a trial run on my next project.

I tend to avoid any classes for singular styles like your 'floatleft' and 'marginbottom'.

If there's little or no forms in the page I stick with the humble
* { margin: 0; padding: 0 }
body { font-size: 100% }
as a starting point..

Think about what you are doing. I am guilty myself of zeroing out all elements!
Say you have a paragraph and its now set to zero - You will have to define paragraphs for the rest of your site. Your probably thinking well I can define a paragraph in the reset also but, even so you could also define other tag elements. So that just proves that using a wild card to zero out all elements is useless. You will learn a lot of new things from this thread. I have!!!!

Yes, but you can reset all properties of all elements with *, and you don't have to set them all back with a separate p, so using * is useful.

Yes, I'm removing the margins and padding from a vast majority of the elements I use in a Web page. I never use a Transitional DOCTYPE (or the code that is valid when using one), so I don't "reset" deprecated (read: obsolete) elements. The vertical alignment in the reset isn't really necessary, but it's nice to keep everything on the same page. As Paul previously noted, form inputs are not included here, since they can cause major issues in Gecko based browsers (and others for that matter).

Here's where I set the default background color, text color, font size, leading (line-height), and fonts. Unlike many people though, I don't over-ride this later on. If I need a dark background color, I'll just declare it here instead. So for those who are thinking of using this as a template, remember that the white and black background and text colors are just placeholders.

Since this stylesheet is meant to be used by traditional browsers on a desktop (or laptop) rather than print, I went with a family of sans-serif fonts that are available just about anywhere. Yes, I can use fonts like Lucida Grande or Tahoma, but the kerning of those fonts tends to make it rather difficult for peopel to read. Granted, Verdana isn't that great at larger sizes anyway, which brings me to my next point. I set the body's font size to be 85% of whatever the browser's declared font size is. For Gecko based browsers like Firefox, this will usually be 16px. While the user can change the font size, they'll have to do so from within the browser. Other browsers such as Internet Explorer and Opera actually respect the system metric, so if you set your font size in the operating system to 18px, the browsers will (likely) use 18px as the default font size. Safari just has to go do its own thing and will set the default at 14px - even on Windows (methinks Apple just has to be different, but then again, they were always a print-oriented company). The leading, or line-height was set to 1.5 (or one and a half times the font size (yes, I realize I'm being far too "general" here, but I'm trying to avoid the technical details since I don't know who will be reading this in the future).

Something you may not know about computers (though since this is SitePoint I'm sure many - if not most - of you do) is the ability to resize the text from within the OS by adjusting its DPI settings (dots per inch). This isn't the "font size" settings, but the actual RESOLUTION of the monitor. On Windows operating systems, "normal fonts" will be 96 .dpi while "large fonts" will be at 120 .dpi - Linux users will need to confirm or deny this, but I'm sure the equivilent for them is 75/100 respectively. As for Macs, well, see my previous comments about Apple (combined with my lack of recent experience with them - I last used one about a decade ago for print design work, and even then I only had "user rights").

Another thing - don't get fooled into thinking that 62.5% = 10px because it doesn't. (The post I linked to will tell you why.) The best you can do is to make sure that the fonts you use are readable on as wide a variety of machines and settings as possible; remember, someone will always have a larger font size declared or may be running "large fonts" (100 or 120 .dpi depending on OS) at 1600x1200; the latter group may not really appreciate those 50px tall (or larger) H2 headings.

Those who are familiar with Eric Meyer's reset.css will recognize this - hey, f it ain't broke, don't fix it, right? Isn't it equally pointless to try and reinvent the wheel? At least we can get all the modern browsers on the same page though, and that's what matters.

Yes, I actually remove the borders from my fieldsets. I use a DIV just outside of them (which are given a class of "fieldset" so I know for certain what they are) for styling purposes. When I float the fieldset DIVs (like when I'm making a search box inline with a horizontal CSS menu) the "display: inline;" gets around an Internet Explorer bug (or twenty ), so it's nice to have, even if I won't be needing it. This especially comes in handy when coding WordPress Themes.

Unlike many people, I actually set the base font size of my headings to 1em (or 100% of whatever the main body text is set to - which in my stylesheets is 85% of whatever the user has it set to). I'll also set the font weight to bold (I prefer to let the browser decide what weight "bold" actually is to reduce the code needed). From there, I'll set the font sizes for individual size headings as-needed. Yes, it's more code, but it's a chance for me to "guide" how large certain headings should be.

As for the images, the two properties and values that are declared are done so with the intention of squashing bugs. I don't like them, and I'm sure you don't either. The first one ironically isn't for Internet Explorer, but Gecko-based browsers like Firefox. When an image is inside an anchor element (you know, a link) Firefox and other Gecko based browsers will tend to put a border around it. This removes it. The other one is designed to push the image to the bottom of the baseline, which "covers up" the ugly "bottom border" many people complain about in Internet Explorer. No hacks, no fuss, no problem!

If you're going to accuse me of stealing from Eric Meyer's head again, I'll confess - as I said before, why bother reinventing the wheel? If it ain't broke, don't fix it! Not only that, but not all browsers render certain elements the same anyway, so having a "default" that works cross-browser really comes in handy (especially among the niche browsers).

Code CSS:

.skip{position:absolute;left:-999em;}

Yes, I use skip links. This removes them. I would like to improve upon it and use a system like what Molly Holzschlag has on her site, but I can't find the article where she discussed it and showed how to do it. If someone can find that article for me, I'd be most thankful.

Now, with that out of the way, there are a couple things I need to say. (Wow, a rhyme.) CSS resets are only as good as the people who are using them, and only if the people using them realize that there are certain values that need to be tweaked/changed/modified/whatever. Time and again, I see people who use a reset technique, such as Eric Meyer's Reset, YUI, or some other reset, who merely throw it in a reset.css file, import it into their main stylesheet, and then over-ride it with other styles - folks, this is a recipe for DISASTER. Instead, why not just put the reset at the top of your stylesheet, add/change/remove the styles, properties and values you need/don't need, and use it as a baseline for the site? Isn't that what a reset is supposed to do anyway? Not only that, but if you modify it and then stick it into the top of the stylesheet (rather than @import-ing it) you'll notice that the page load times actually decrease, meaning that it won't take as long for the browser to fetch the stylesheet in the first place. And anything we can do to enhance the user experience should be towards the top of our priority lists anyway since it's a win-win solution.

The other thing is that a CSS reset is only as good as the HTML code that goes along with it. My reset only touches upon the baseline stuff - things like document structure, layout and positioning really don't get used since they're presentation-specific things, and I don't like my resets to cause problems with other peoples' code - especially when I'm debugging it.

So to recap, here's what I (generally) do. I start by putting the reset at the top of the stylesheet. I actually put the code there, rather than calling it through an @import. I'll then code the layout parts of the stylesheet next in a source code order (header, menu/s, content, sidebar/s, footer). Here's an example of the HTML and CSS working together (I'm only including the HTML that comes between the <body> and </body> tags.)

If there's anything you folks think can be done to improve upon this, just reply here. Since we're talking about CSS resets, we might as well talk about what makes them work, why they work, why they don't work and what we can do to make the best ones possible, right?

Thanks Paul for your article-- now that I know what the problem was with form elements exactly, I can leave off even more in my padding resets. Or I can keep my simple reset and make :active styles for inputs if needed.

Originally Posted by Dan

I never use a Transitional DOCTYPE (or the code that is valid when using one), so I don't "reset" deprecated (read: obsolete) elements.

Dude, what's with the tt in your reset? isn't either kbd or code more appropriate, depending on what you're using it for? I thought tt was obsolete and not recommended. Though I learned something new -- didn't know about the dfn tag. I can already think of a few places to use it : )

Dude, what's with the tt in your reset? isn't either kbd or code more appropriate, depending on what you're using it for? I thought tt was obsolete and not recommended.

It's still valid in HTML 4.01 Strict, XHTML 1.0 Strict and XHTML 1.1. It's highly presentational, though, and should only be used to adhere to a typographic convention that dictates a monospaced font. I might use it to mark up file names in an example, as in

Code HTML4Strict:

<p>Save the file as <tt>index.html</tt> and open it in your browser.</p>

Originally Posted by Stomme poes

Though I learned something new -- didn't know about the dfn tag. I can already think of a few places to use it : )

Just make sure you understand what it's for. It doesn't mean 'definition'. It's for a long-standing typographic convention, especially in technical documents, to italicise the first occurrence – or defining instance – of a term with which the reader is not expected to be familiar.

Code HTML4Strict:

<p>Web page presentation is controlled via a <dfn>style sheet</dfn>: a set of rules for how the content should be rendered.</p>