melbourne chapter

I have been doing some compliance based development at the moment, and I found the easiest way of handling your CSS is as follows (my current recommendation):

Create a directory for each major media, e.g. “css/screen” and “css/print”. I tend to prefer seperating my CSS into two sheets. Layout CSS (layout.css) purely defines any required layout of divs, and mainly governs the CSS properties; float, margin, padding, position, top, left, overflow etc. All those relating to laying out our design. The site CSS (site.css) defines our other global colours, backgrounds, fonts, borders and the like.

Usually this break down allows us to work in a series of steps.

• Our first it to write pure (validating) HTML, writing it looking like a beautiful word document, without any formatting, but concentrating on clean clean code, valid code and follow all recommendations programmatically required by W3C accessibility guidelines.
• The second step is to step into the Layout mode, where you position our elements into our layout.
• Our third is to make the site rich with colour and match our PSD/Design.

I have found this approach usually allows a few different developers to work concurrently, as one can work on layout, while another is extracting graphics and worrying about colours etc.

I start with the “screen” media and then once done I work on the “print” media. Most of the time all we have to do is hide out components, such as verbose navigations etc, using the simple CSS properties, such as

div.nav {
display: none;
visibility: hidden;
}

We could go further and colour up the print out, but generally we like it clean and easy to read, most of the time Serif fonts will print and read easier.
Next when I go to include the CSS in the header I specify the media with the media attribute;

<link rel="schema.dc" href="http://purl.org/metadata/dublin_core_elements" />
<link href="css/screen/layout.css" rel="stylesheet" type="text/css" media="screen, tv, projection" />
<link href="css/screen/site.css" rel="stylesheet" type="text/css" media="screen, tv, projection" />
<link href="css/print/layout.css" rel="stylesheet" type="text/css" media="print" />
<link href="css/print/site.css" rel="stylesheet" type="text/css" media="print" />


Now that I have organised my folders correctly, and I have specified the media it is easy to analyse where to make various changes to my CSS code.
Most importantly, to work across different browsers such as Internet Explorer (IE6 PC or IE5.1 Mac) It is important to include some conditional inclusion of CSS that will overwrite previously declared CSS rules for a specific browser. These are often called Box Hacks. There are many box hacks out there, often they are about stopping the processing of a CSS rule by a browser’s CSS “parser” at a certain point; usually some browsers will continue reading when others decide not to.

Often this means that you end up with a CSS document full of various hacks and definitions of widths and heights, paddings and margins, side by side, without really allowing us to deal with them seperately. Often this ends up like a soup of code not making much sense, with various asterisks, and useless definitions you are unsure if they are being picked up or not.

I prefer to define all standards compliant CSS from the start, without worrying about IE compliance. As IE requires changes to CSS rules to match the normal, we add extra style sheets after we have included all our standards complaint CSS rules and then set them to overwrite the rules previously defined for individual non-complying sheets. Doing this means that I like to start with a standards compliant browser such as Mozilla Firefox for development. Get it looking right here, validating both your XHTML/CSS and Accessibility.

Now to worry about those browsers that don’t comply to the standard “box model” or handle rules the same as the standard.

The other you include your CSS documents in your HTML is very important. If you have defined rules in one sheet you include, if the next file you include defines the same property it will overwrite the previous rules. We take advantage of this by creating 2 seperate CSS documents that will contain our CSS hacks, cleanly presented in their own document. I recommend naming them “css/screen/IE6.css” or “css/screen/IE51.css” depending on which rules you are overwriting.

You can then include the extra lines in your header of your HTML after your standards compliant SCREEN/PRINT media CSS docs. e.g.

PC IE 6 Box Hack

Seperate style sheet (seperate CSS document) overwriting specific rules without cluttering your standards compliant CSS docs. This also is forward compatible with IE7 as it is only included on upto and including version IE6, and is recommended by Microsoft:

<!--[if lte IE 6]>
<style type="text/css" media="screen, tv, projection">
@import "css/screen/ie6.css";
</style>
< ![endif]-->

MAC IE 5.1 Box Hack

By seperate style sheet. This exploits the fact that IE Mac 5.1 would read in this style sheet where others will not:

<!-- MAC IE start -->
<style media="screen" type="text/css">
@import("css/screen/ie51.css");
</style>
<!-- MAC IE end -->

Overall stucturing your CSS this way allows us to centrally write standards compliant CSS and creates a nice workflow for handling our CSS. You can start with firefox, then load into IE and place in some specific rules that will make your CSS work as predicted in IE.

Making good use of the media attribute is important also.