There’s been a good bit of talk lately about CSS resets, and how good/bad they are. This conversation tends to come up every 6 months to a year and always gets people excited. This time around, Jonathan Snook’s No CSS Reset is “the culprit”. I think his general sentiment is good, and he comes to almost the same conclusion, except that I’ve actually created the Base CSS file that he speaks of. More to follow…

The Ugly

I’ve seen lots of people use a star reset: * {margin: 0; padding: 0;}. If you use this by itself, and you aren’t resetting margin and padding on other elements like headings, p, and form elements, you are going to get bitten. Hard. Firefox and IE6 are the special offenders here: form elements, especially checkboxes, radio buttons, and selects will get styled especially poorly and need to be restyled with some padding or the arrows won’t appear, or they become impossible to select.

The Bad

The bad is when you don’t do any common groundwork; every project means you start over and you avoid CSS resets like the plague. Ok, so this isn’t really all that bad, but it’s going to cost you a lot of time in the long run, especially if you’re developing on a team. What happens when you have the n00b that doesn’t understand some of the nuances of cross-browser text sizing, or the way different form elements are handled? You’ll probably say “educate them!” or “then don’t let them touch it until they know what they’re doing!”, but that essentially makes them non-productive. It’s bad practice to make CSS more magical than it already is; give everybody a headstart and lay a common framework.

The Good

As usual, we want to find the middle ground.

I think Eric Meyer’s CSS is moving in the right direction, but it’s a bit bare at the end result. I think the point of a base CSS is that it’s supposed to look decent after you’re done so that you don’t have to think about every style. The idea is to make it look very similar cross-browser, not to pull a Dark Ages Catholic Church and reset everything. Eric mentions this in his article, but a lot of people just download and plug it in.

There are plenty of UI frameworks out there that have a common CSS file that they use, mostly filled up with proprietary classes and IDs, but you can often extract bits and pieces from the generic parts to use. The point is, rather than resetting everything, you can instead create a foundation or base for your CSS to at least make it cross-browser friendly, and at least presentable by default.

I’ve been using my current base.css file for about 3 years now, and I update it from time to time. Feel free to use it if you’d like. You can see it in action at http://labs.zorked.com/lib/base.html

Download: Base.css

This post will be more relevant in the future when more browsers support the new CSS 3 Selector specification, which includes a lot of neat attribute and pseudo-element selectors, among other things.

I’ve been looking for a way to do alternating table rows with CSS only; no JavaScript and no adding class=”alternating” to the tr element in server-side code. After a tiny bit of experimenting, I found the following solutions:

Alternating every other row:

tr:nth-child(odd) {
background-color: #CCCCCC;
}

tr:nth-child(even) {
background-color: #6699FF;
}

Changing between 3 different colors:

tr:nth-child(3n-2) {
background-color: #FF9900;
}

tr:nth-child(3n-1) {
background-color: #006633;
}
Read the rest of this entry »

I like my CSS to be right. And by right, of course I mean “my way”. Now, I try not to be anal-retentive about many of these things, but they’ve been valuable for me in easing maintenance work. They provide consistency and readability, which is what I like, since I’m lazy.

Now, everyone and their mom (assuming their mom is a web developer/CSS guru) has already gone over how they like this, so I know I’m beating a dead horse. However, I think it’s worthwhile to explain why I do it this way.

Property assignments

For example, display: block is a property assignment. There are two rules here. First, I keep all property assignments within a block alphabetically ordered so that I can find them with no problems.

Example:

.section {
background-color: #F00;
display: block;
height: 100px;
text-decoration: blink;
width: 200px;
}


I generally keep them in this format: the “sort of compact” method. The selector goes on the first line, along with the opening bracket. Then, all the property assigments are listed, one per line, and then the closing bracket is on its own line. Nice and readable.

If there is just one property assigment, as is the case with certain things, everything will go on one line, from the selector to the closing bracket. ex: a:link {color: #600; }

Declaration ordering

I try to keep all my declarations in the same type of hierarchy as they would normally appear in an HTML page, or however makes the most sense. Generally, tag-based selectors (h1, a, p, marquee [just kidding]) all come at the top, followed by class selectors for repeated elements, and then finally for single-use, ID selectors.

File hierarchy and structuring

This is really the most important part: how you organize the way you store your CSS files on your site. In Roots, the way I’ve split up my files is first by media type, and then by function. In addition to separate files for each media type, I create little snippets for layout, color palettes, typography, forms, etc. By allowing SSI to process my CSS files, I can keep everything organized and easily maintainable, yet only have one file that the client has to download.

Here’s the quick rundown:

Common CSS

/common/ - this is where I keep snippets that are used among media types, examples being the subfolders below…
»color-palettes/ - all main color for every element on the site is stored in a color palette CSS file, so that I can change color schemes at any time.
»typography/ - obviously, for all font declarations. Once again, I can change the typography with one line change. This is especially useful for when different media types require certain fonts.

Screen CSS

/screen/ - All code for the screen media type, including some files that simply reference a file in the /common/ folder. The main file here is screen.css, from which everything else is SSI’d in.
»color/ - This is one of those places where it’s just a reference to a color palette. I also include some overrides or additional declarations, if necessary.
»layout/ - This is where anything related to layout of elements on a page is stored. Layout grids and code snippets galore!
»»grids/ - I store a variety of grids here, generally for 1-, 2-, or 3-column layouts. Any one of them can be swapped in at any time
» - In this /screen/ folder are files for the header and footer, navigation, forms, and standard content. Keeping them separated helps for maintenance–if something’s wrong in the header, I don’t have to sort through a bunch of declarations in some huge file to find it.
»typography/ - this, like the color folder, is simply a place to reference which typography palette I wish to use.

Print CSS

/print/ - All code for the print media type. This is much more trimmed down than the screen folder.
»color/ - Once again, the color folder, for the same purpose as in the screen media type
»layout/ - This folder is for print layout, and only contains 3 files: base.css, content.css, and layout.css. Base.css is for setting up print-specific things, such as paging. Content.css is for standard elements, and layout.css is for basic layouts…no grids here, most likely.
»typography/ - Just like the screen media type

Handheld CSS

/handheld/ - All CSS for the handheld/small screen rendering goes here.
»color/ - The infamous reference color folder appears again.
»layout/ - This folder contains header and footer, navigation, forms, and basic content, just like the screen layout folder, but does not provide anything for grids, since that’s not very good for handheld devices. Basic layouts can be done in the content file.
»typography/ - Typography’s folder is here to join in the fun as well.

Aural/Auditory CSS

/aural/ - There’s just one file here, since there’s not much to do for aural. Not much support these days, so what can you do?

Sections and Pages

/_sections/ - Whenever you need to override or add some styles for certain directories/sections of your site, they go in here.
/_pages/ - For page-specific overrides, you can put a CSS file here rather than using inline styles if you want to have some of the benefit of SSI parsing or client caching.

Base.css - Default style simplification

Let’s not forget the magical base.css file, which tries to reduce as many of the differences in default styling among browsers. Mostly, this is margin and padding work, but also there are some font sizing things and list edits to take care of.