There are a large number of CSS frameworks freely available, so why write your own? There are two main benefits. Firstly: you will know and understand what you’ve written. Secondly, you will be able to customise your code to suit each project. This article covers the first steps: setting your objectives, creating the basic file structure and incorporating the files into the website.

There’s a lot to consider, where do you start?

Start by deciding what you would like your framework to do. My primary criteria was to separate out basic structure from style. I’ve worked on content management systems that controlled multiple sites which shared the same content, but had their own colour schemes. In that case each site had it’s own colour.css file.

When planning also consider how styles are going to work. My framework has styles that allow me to set widths for items using classes. The benefit of this is I can change values in my grid.css file and have the whole site change width easily. Currently I’ve separated all colours into a single file, all font sizes into another, all font styles into another and so on. I find very easy to control styles but have ended up with a greater number of individual files than I might wish for.

File structure

One of my goals for the framework is to have a stable structural core that could, in theory, be swapped between site without any adverse affects. To this end there is a ‘core’ sub-folder within the main css folder.

Calling in the files

When using multiple style sheets it’s much neater to reference them all from a single parent:

/* resets unwanted assumed values placed upon certain elements by certain browsers */
@import url("css/core/reset.css");
/* the basic structure of column widths and gutters */
@import url("css/core/grid942.css");
/* basic formatting for horizontal and vertical list menus */
@import url("css/core/menu.css");
/* basic formatting for forms */
@import url("css/core/forms.css");
/* definition lists */
@import url("css/core/definitionLists.css");
/* basic typographic styles */
@import url("css/fonts.css");
/* type sizes */
@import url("css/typesize.css");
/* colours and background images */
@import url("css/colours.css");
/* structural and typographical details specific to site */
@import url("css/details.css");

Core files

As mentioned above, the aim is that the core files are stable and remain untouched. The files are as follows.

Reset.css

Although some argue against their use, I’ve used a rest file to remove unwanted values from various elements. I’ve used Eric Meyer’s reset.css. The benefits are reduced code in other style sheets and reduced use of !important declarations.

Grid942.css

All my designs use a 12 column layout grid, and I base the widths of my designs on pixel values that can easily be divided into the required number of columns and gutters. The classes in the files give values to padding, margin and width values that fit the grid.

Ie6.css and ie7.css

These files, called in using conditional statements, provide browser specific tweaks for any supported versions of Internet Explorer. Happily, these files usually contain very little. Check this reference page for more on the conditional statements supported by Internet Explorer

Other core files

Menu.css, forms.css, and defilitionList.css simply contain some basic formatting that I know I’m going to want to use for formatting those items.

Non-core files

As with the core files, it’s personal choice. The files I have change as the framework develops.

Currently I’ve got:

• colours.css – all colour values and background images
• typesize.css – all type sizing
• fonts.css – all font styles
• details.css – everything which has not covered elsewhere
• print css – ‘calls in’ the syles required for printing and contains a few print specific styles
• styles.css – to ‘call in’ all the style sheets

Document head

The code below ensures the correct browser specific styles are being referenced and fetch the print styles when required:

<link rel="stylesheet" href="http://www.creativeglo.co.uk/wp-content/themes/myNewTheme/style.css" type="text/css" media="screen" />

<!-- IE SPECIFIC BUG FIXES -->

<!--[if IE 7 ]>
<style type="text/css" media="screen">
@import "/wp-content/themes/myNewTheme/css/core/ie7.css";
</style>
<![endif]-->

<!--[if IE 6 ]>
<style type="text/css" media="screen">
@import "/wp-content/themes/myNewTheme/css/css/core/ie6.css";
</style>
<![endif]-->

<!-- PRINT STYLES -->
<link rel="stylesheet" href="/wp-content/themes/myNewTheme/css/print.css" type="text/css" media="print" />

Document your work

Documenting what you’ve done is absolutely essential. Maintain a change log file to keep track of what’s been added, tested, removed and so on.