John Barclay

Programming

Tips and Steps for Developing CSS

I've written CSS for template driven sites a number of times, and this is my approach. It has a programmer's slant on it. This is written for developers with moderate HTML and CSS experience. Its more geared towards those doing CSS stylesheets by hand rather than a CSS generating tool. The example I reference is the College of Education at the University of Illinois at Urbana-Champaign (COE) where I work. This site is in the development phase. I'll link to it when its released.

My Steps

Decide what browsers you want to support. Make a list of test browsers and how close to your design you expect your CSS to achieve in each such as perfect, good, tolerable. I prefer to design for standards compliant browsers and make sure the design fails gracefully in older browsers. However, popular non-standards browsers such as Internet Explorer 6 may need to be accomodated.

Remove layout tables from the content files you are doing css on. I've been working on CSS layout and just couldn't get it to behave correctly only to find that burried in the editable/content regions is a <table width="100%"> table that is the culprit. Realize that any conversion from using tables for layout to CSS may require cleaning up html contents within editable regions of templates.

Do positioning CSS first: margins, padding, float, width, etc. to make the layout work. Start using one stylesheet for all the templates in your site. Use the body#id or body.class selector as mentioned in the tips section to differentiate rules that only apply to some templates.

Valdidate HTML and CSS using W3C validator as you develop it.

Test initial layout CSS in your suite of test browsers. It should include at least one standards compliant browser such as Firefox and a particular popular non compliant browser (Internet Explorer 6). Be sure to test the effects of screen resizing, screen size, users turning off style sheets, and users changing the font sizes.

When you are happy with your layout CSS, do non-positioning CSS. Color, background color, font, etc.

Retest. Get approval for test pages with one CSS sheet.

Now that you've got your result, you need to get your style sheets organized for production release. There are many approaches to organizing and including stylesheets. If your style sheet isn't too long, you can keep your style sheet in one file when your site goes to production and leave the comments in it too. This makes maintenance easiest as you never lose track of comments. Remember that browsers will generally cache CSS files just like they do images. If you decide to split the CSS into mulitple files, make a single CSS file for CSS that applies to more than one template. Something like common.css. Make separate CSS files for each group of templates or each template, depending on how much CSS they have in common. Take out the comments in the production version to improve download times if your CSS file represents significant load time, and you are worried about it. In the COE site we have 3 CSS files: common.css for all pages; home.css for both the unit home and coe home templates; and standard.css for the standard and standard sidebar templates. In all they total 40kb.

Tips

Don't count on the sequence of rules for specificity. Its too easy to mess things up when rules get shuffled around. The exception to this is the child selector hack which generally has 2 rules with the same specificity except for the order. This hack is most readable when the two rules are next to each other. Use higher levels of specificity in your rules as you work down into the document and and the order of the rules will not matter. Such as body {} for general rules and body.homediv.navigation {}. Such an approach best utilizes the cascade or inheritance features of CSS. See http://www.blooberry.com/indexdot/css/topics/cascade.htm for more info on specificity.

Use class and id attributes in the body element to identify which template is being used. Use a unique id attribute for each template and a unique class name for each group of similar templates. This allows you to use a single stylesheet in the development process while you sort out which styles apply to all templates and which are specific to individual templates. I find that jostling rules around in a single stylesheet helps me see patterns and differences within templates and elements within a single page.

In the COE's site, we have four templates: College Homepage, Unit Homepage, Standard, and Standard Sidebar. Our body tags look like this:

Have a consistent method to grouping and ordering to your rules. This makes it easier to read your own CSS. I like to have the CSS rules grouped by top level HTML elements such as the navigation, content, header, and footer divs. This way I can give an example of the relevant HTML in a CSS comment and follow it with the rules for all the elements within the top level element. Within that grouping of rules, I put the rules from outer to inner elements. When more than one rule applies to an element I put them in order of specificity, lowest to highest to make it easier to follow the declaration's inheritance by reading the CSS top to bottom.
If an HTML element is unique to single template, I put that section of CSS near the bottom of the stylesheet.

Within a block of declarations applied to a block element, I like to divide the declarations into 3 groups. I put the layout declarations at the top (postion, height, width, float, margin, border, padding etc); text and color styling in the middle (color, font-face, etc); and background (color, image, z-index etc) last. I separate them with a blank line. Layout CSS work is more time consuming for me and generally requires more hacks so its handy to have layout declarations at the top.

If you have minor variations of a rule, group the common declarations in one declaration block and the variations in the following rules. This makes it easier to scan for similarities and differences.

Use id attributes for any element that appear only once in a document. Use class attributes for element that may appear more than once. If an element has specific functional role such as a navigation div, use an id or class name that describes its purpose. If the element is merely there for styling such as a layout div or a span used to style text, give it a class name that describes its effect rather than pretend the element has a higher, structural purpose. Good class and id structure will also help with javascript and xhtml validation.

If two classes must be applied to the same element, use class="a b c" syntax rather than using redundant nested divs or spans. For example use <div class="leftAlign data></div> rather than <div class="leftAlign"><div class="data"></div></div> Though Internet Explorer 5 and 6 won't support selectors that use the intersection of 2 styles such as p.style1.style2, it is easy enough to avoid them. A simple example can be seen at: http://catcode.com/csstips/classes.html

Put examples of HTML structure in your CSS code in comments. You can cut the comments out in the production version. This helps in seeing how the HTML and CSS are connected and can help designers and programmers work together. The examples below are comments from the COE style sheet.

Don't use separate stylesheets or browser detection for Internet Explorer 5 and 6 CSS hacks . It isn't needed and only complicates your development process. Furthermore Opera disguised as IE can foil browser detection and make hacks such and the PNG transparency fail. Separate stylesheets also mean changes must be made in 2 places and you need to validate multiple css files. Use conditional comments for IE CSS hacks.
The child selector hack no longer works because IE 7 implements the child selector. Use conditional comments for rules that you only want to be seen by particular versions of IE.

Conditional Comments. This allows certain rules only to be seen by IE 5 through 6. Since the conditional operands don't appear to have boolean operators, you must have a single rule such as less than IE 7 or greater than IE 5.5. Thus a rule that applies only to IE 5 and 5.5 would need to repeated twice with separate conditional statments.

Browser Toolbars

Take the time to install and learn browser development toolbars. They will save you time and suffering with CSS as well as HTML, javascript, forms, etc. With single clicks from your browser's toolbar, they will show the HTML structure of your document, validate your CSS, show what the browser looks like in different size windows, show cookies available, outline DIVs without debugging CSS borders, show you what your page looks like with scripts, css, or images turned off etc.