How to structure large CSS files

Many methods exist to structure your CSS. This article tries to describe the method I use. I call it the “Tree method”, since it structures the CSS like… that’s right, a tree structure. I want to stress that it isn’t my invention; I just describe and give reasons for its rules.

Everyone that has built a bigger site has had to deal with the mess CSS so easily become. There are ids and classes all over the place, and to find where a certain class is defined you usually need to use some search feature in your editor. Matching the other way, from the CSS to the HTML is even harder; you don’t even know what file a certain class is defined in. It’s a mess.

The Tree method tries to structure the CSS into logical blocks; blocks taken from the HTML. It also aims to be easy to understand for anyone. No secret codes or difficult ordering schemes.

Order your selectors like the HTML
Always use the “full path” to elements
Indent your code cleverly
Each declaration on its own line
… in alphabetic order
Order your selectors like the HTML
One of the problems of mapping between the HTML and the CSS is that they usually differ in structure. The HTML is (if you’re lucky) structured like a convenient semantical tree while the CSS often is ordered by something random like fonts, colors, and positioning.

To make moving between the two worlds easier we want to make them as similar as possible. Is the HTML divided into header, content, and footer? Then make sure that’s the three major parts of your CSS as well. Have you put the navigation above your header in the HTML? Then order it like that in the CSS as well! Any other structure makes moving from the HTML to the CSS much harder. You might be able to find all font manipulations in one part of the CSS, but only if you know that this particular developer uses that exact scheme. No, let’s keep it simple.

Here’s a simple example where we just order the selectors:

#header { ... }
h1 { ... }
h2 { ... }
#content { ... }
p { ... }
em { ... }
strong { ... }When grouping several styles into one definition I just put the group above both of their specific styles. #header, #content comes before both #header and #content.

Always use the “full path” to elements
The above is very easy to get an overview of, but the experienced developer knows that very few sites are that easy. Something you often want is a way to define different styles to different parts of a page. Let’s say you want green links in the navigation, but want to keep them blue everywhere else.

For this we use sub selectors. The selector #navigation a lets you give all links inside your navigation another look. But let’s take that further. Why not always write the full path to your elements? Why not use #navigation ul li a instead? Doing this gives a developer looking at your code a lot of information about how the HTML and CSS belongs together.

Lets add that to the previous example:

#header { ... }
#header h1 { ... }
#header h2 { ... }
#content { ... }
#content p { ... }
#content p em { ... }
#content p strong { ... }This does change the meaning from before. Before we selected all the level two headers; now we only select headers inside of the header division. Extending each selector with a “path” has made our CSS rules more specific, and specific means more control for you.

This also makes for fewer new ids and classes; just specify the path to an element instead of adding a class for it. Don’t add a new class or id unless you really need to.

We still have the issue of “common styles”; styles that we want to apply to elements in different parts of the tree. Since they should be applied to all elements they don’t fit in the tree structure we’ve built. Instead we make a section in the beginning of the file (or a separate) with just “general styles”. Don’t add rules to this section if you only use them once in the document, you want as much of your code to be in “the tree” as possible.

Indent your code cleverly
To make the code even easier to understand I always add indentation (for those that don’t know that word: it means spacing in front of blocks of text). Indenting makes the tree structure we’re trying to build even clearer, you can easily find the major sections and dig down from there.

Lets add indention to you our example too:

#header { ... }
#header h1 { ... }
#header h2 { ... }
#content { ... }
#content p { ... }
#content p em { ... }
#content p strong { ... }Don’t take indentation too far. If you’re styling tables and using thead in the markup, but don’t change the style of it, you can skip that indentation level. Double indention just for the sake of it is just a waste of space.

Special case: Templating
We also need to deal with rules that only appear on some of our pages. Perhaps we want the home page to look somewhat different than the sub pages? We solve this by giving an id or class to the body element. Doing this lets me specify styles for just one specific page, and setting the id or class on body makes me able to change anything in the document based on that.

These page specific styles need a place in the tree too. Here I tend to break from the above scheme and put them together with the style they change. So body#page_home #header h1 is one step below #header h1 in the tree. That makes it easier to see all styles for a certain element, instead of scrolling back and fourth (like you need to do if you don’t remember your general styles). Keep your templates together with the style they change instead of completely separate.

If you want bigger changes, perhaps a totally different look on some pages, there’s no reason to group things according to the scheme above. Move them to a separate file instead.

Each declaration on its own line
Indentation combined with full paths makes some lines rather long. This means that putting all declarations on one line will force you to scroll horizontally, something we already avoid on our sites. The simplest way to prevent horizontal scrolling is to use one declaration per line, so that’s what the tree method uses.

… in alphabetic order
Grouping of properties is another issue. I’ve seen grouping schemes based on all sorts of things; from splitting things into “positioning”, colors, and fonts, to people adding their properties completely randomly. I’ve chosen to just order them alphabetically. It’s one of the few methods that bring some order while still being simple enough. I’ve seen total beginners do this by themselves; something I believe is a good argument for it. It’s intuitive.

A simple example to illustrate:

#content {
color: Blue;
font: 3.4em Arial, sans-serif;
margin: 0.5em;
}One complaint I’ve heard on this method is that it splits up things that belong together. People tend to keep position: absolute and left: 0 together, just to name one such pairing. It annoyed me at first too, but declaration blocks rarely contain more than 10 declarations, and the alphabetic order still makes them easy to find. Also, why handle position different than float and margin?



That’s it! By following a few simple rules you can get a CSS-file that’s easier to overview, a file that you proudly can give away to the next developer. I can praise its existence all day, but you’re the judge of whether it works or not. Why not give it a try in your next project?

Cross browser CSS for your site

This article will go through some useful cross-browser CSS techniques I use to get my sites to look the same in several modern browsers. It’s fairly easy to send out different versions of your site to different browsers. This should be avoided though since it will end up with you having to maintain the site as if it was in fact several. That defeats the whole purpose with standards, why are they even needed if you are adapting to the browsers instead? My opinion is that good cross-browser coding is to find the set of standards that are supported and then use them.
Validate your site
Validation is a much debated area and many Level 2 bosses doubt that this procedure really helps. It does help though. It ensures that you didn’t do any simple spelling errors, things that could be incredibly hard to find manually. A validator also checks for nesting errors (did you put a

inside of an anchor?) and other strange things like your character encoding. Information about each of the errors is available as links when they appear, just click on one and you’re on your way to learn something new.
Validation is the simplest of my tricks to check. There are validators available for both (X)HTML and CSS. Use them! Any errors that show up on those lists could be a potential cross-browser breaker so if you decide to ignore any of them you should be really sure about what you are doing. There are reasons why each one of all of the errors on the validation page show up, so validate, fix, validate, fix, validate.
Stay in standards mode
The next trick is not as obvious. Modern browsers have two rendering modes they use to display websites with: Standards mode and Quirks mode. Standards mode is a rendering mode that is made to work according to the W3C specifications as closely as possible and Quirks mode is a bug ridden mode made for older sites. Why have a mode with bugs you ask? It’s a way for browser makers to keep their users happy. When you do big changes to your rendering engine a lot of old sites relying on browser bugs will break. Some might think that this is a good thing, why should sites still work when they are poorly coded? If you think like that you have forgot about who the web is for. It’s not a place for experts only, it’s made for regular users, that is, anyone with a browser. Those people need to see a working site if that’s possible.
So a new browser is released with a more standards compliant rendering mode and pages start to break. This is a bad thing for users so browser makers decided to first identify pages that tried to follow the standards, and if they did, switch to the new and improved rendering mode. You will probably see why I recommend standards mode now. All browsers are trying to render things as similar to the specs as possible when in standards mode, while in quirks mode they keep all their old bugs just to help regular users.
So how do the browsers identify who’s trying to follow standards and who’s not? They use the doctype. If you’re not familiar with doctypes, don’t worry, they are easy to learn. A doctype is a tag on first line of your site file telling the browser what markup language you will be using. There are basically two doctypes you should select among:
HTML 4.01 Strict (what I recommend):

XHTML 1.0 Strict (without on the line before)

Using any of these make sure the browser switches to standards mode and your design not fail because of that. Using a strict doctype means that you will do your best to separate structure from design and the validator will give you errors in those areas. It’s very useful. (Worth a small note is that the XHTML Transitional doctype also triggers standards mode, but while using transitional you don’t get as many good validation checks so don’t use that one anyways.)
There is one last catch one needs to talk about when dealing with doctypes and standards mode - the doctype needs to be the first tag in the document. If you put any HTML comments or strange characters before it IE will go crazy and switch to quirks mode. This has cause many developers countless hours of trying to fix things. Just don’t do it!
Remove default styling of elements
Another cause of many web developers screaming in the night is the default CSS that is applied to elements. If you don’t use any CSS at all on your page elements will still have a certain look. Headers will be larger than text paragraphs and blockquotes will have padding. Sizes of text is something that is pretty similar across browsers but something that’s not is padding and margins. Let me give you an example: With no styling an "ul" gets a padding in Firefox but a margin in IE. Solution? Set either the margin or padding to zero and set the other one to the indentation you want. You need to somehow remove the default browset styles.
These kinds of problems take up a lot of development time if not handled nicely. “Do definition lists in Opera have padding or margin?”. “What about second level headers in IE 6?”. Two schools of thought have evolved to handling this. The first one tells you to start by resetting all margins to their defaults at the top of you CSS file. This can easily be done by typing in * { margin: 0; padding: 0; }, * being a universal selector that applies the same rules to all elements.
Problem solved right? That’s where the second school of thought comes in. They argue that too many default margins are reset. Why should we mess with users form fields, rendering them hard to use unless they are set to good values again? Instead you could just reset those elements that have differences, and leave the rest untouched. This is quite a lot of work to get right so Faruk Ateş built a “starting css” template that you can easily include in your head. Personally I prefer the *-method, but try both and decide for yourself.
Browser bugs
This is the area where CSS gets hard. Even though browser makers work their asses off to follow standards they sometimes don’t reach their goals. This leaves us webmasters with bugs that when fixed triggers new bugs, either in the same or another browser. It can easily get real dirty.
One of the worst browsers (that is widely in use) is Microsoft’s Internet Explorer, version 6. Some claim they have about 80% of the browser market so it’s not a browser you can just ignore. IE was a good browser when it was first released but by today’s standards it’s certainly not. No other browser caused me more pain while building the design of this page. Its shortcomings get painfully clear when it comes to rendering complex CSS layouts.
How do you handle these bugs then? The easiest (and fastest) way is not solving it yourself but reading up on someone else’s solution. “Holly ‘n John” have gathered the most frequent bugs on their page Explorer Exposed!. They give you examples of how to detect the bug, how it works and why (sometimes) and most importantly how to solve it. Sometimes the solution is just setting position: relative; or display: inline; on some element and sometimes you have to resort to strange code. The point here is that if your bug is on that page; don’t waste time trying to figure it out yourself. Learn that list by heart.
So what do you do if your bug isn’t on the list? You start by googling for a solution of course. Googling takes a few minutes compared to the hour you probably need to hunt it down. Don’t underestimate this step.
If you don’t find it somewhere you need to hunt it down yourself. Do this by making a copy of your page and then removing as much code as you can while keeping the bug. Then find out exactly what line (or lines) of code that causes it and finally try to find another way of doing what triggers it. This is much better than just throwing in hacks, you keep your code maintainable and you learn a lot more useful stuff than if you were throwing in nonsense code from the beginning.
If you for some reason do not manage to solve the bug with the above technique you either rethink what you are doing (not likely) or you go get your arsenal of hacks. Make sure the hacks are valid code. The one I use for IE when nothing else works is the “* html” hack. You use it but writing like this: * html #element { code; }. That selector selects all tags that have the child html that have the child #element. But “html” is the topmost element in the hierarchy so nothing is selected, unless IE can choose of course. The code gets applied in IE only. Note that it is perfectly valid CSS, it just doesn’t select anything. Remember: hacks are your last resort when nothing else works.

I hope you found something useful in this article that you can use when you get cross-browser CSS problems. I have now told you what steps I use, did I miss something? Do you do something differently?