’practical’ btw..

I’ve modularised in my web-applications thusly:

1. Index CSS file (global properties common for all elements)

2. page level CSS files (where layout might differ, or content mandates changing padding/margins)

3. inline styles on certain pages where I want an exception (overriding a global property) (no reason they are inline really.. they could very well be in the page level CSS)

I have one exception, in that I had one module of code for Validating form fields, and I’ve seperated the CSS for that.(required label colors, and various and sundry things)....

I tend to break down a sites into a series of includes that my content pages call.  These are global elements in my design (header, navigation, footer, etc) that will stay consistent for branding purposes.  My CSS files tend to mirror this structure and I add additional CSS files for page specific content when needed.

# base.css
# global.css
# structure.css
# page specific css
# header.css
# navigation.css
# footer.css

Note: “Live Preview” doesn’t match the end result when you publishing comments. # was intended to be an ordered list.

What kind of backend are you thinking? Are you looking at Expression Engine for client projects? I wrestle with this all the time with EE templating (using {embed}). EE doesn’t (at present) make it really easy to pass variables to nested templates, so it’s mostly hacking at this point.

I’m with you on the “level of granularity” thing. I try to get the big chunks (low-hanging fruit) in separate CSS files, and then put page-specific stuff on individual pages. I like having one ‘global.css’ that @imports the others (fonts.css, positioning.css, etc.). It really depends, for me, how similar the templates are as you go into the site.

I tend to work my stylesheets toward the two main media types (screen and print) - I’m not sure how advisable that is, but it helps me keep track of things fairly well.

I tend to develop the screen stylesheet first, until I have everything looking as needed. Then I revise the design for a print style, removing the navigation and any superflous features that are likely to waste paper of affect legibility.

I’d be more inclined to use flags/comments within the CSS for easier navigation.

Gerard McGarry: When specifying media types in CSS, you should let the “screen” stylesheet apply to the “projection” media as well or the page will be unstyled in Opera’s fullscreen mode. Unless you have a separate “projection” style, that is.

To get back on topic; I tend to use flagged CSS for my projects. However I’m usually working on small-scale, personal projects with relatively few styled entities.

I’ve experimented with multiple methods over the years for organising CSS, and the conclusion that I’ve come to is that I like to send the smallest amount of data with the least number of trips to the server…

So, I organise my CSS by roughly following the HTML source, or functional grouping (header, content, nav,footer). I try and fit it all into one file, and use the cascade as much as possible—minimizing classitis and iditis. Occasionally, I use page specific CSS in the documenthead, but if it’s needed in more than a couple of pages it goes in the CSS file.

I develop in the most standards compliant browser available, and put any hacks, if needed, at the end of the file as I build up support for not-so-compliant browsers.

Usually I only need the * html hack, and a comment hack for IE5/Mac. If I have more than a couple of IE specific rules, or I’m using expressions then I’ll use conditional comments.

I comment my working files and compress anything sent to a browser.

For me it comes down to how best deliver data quickly, and so I’ll adjust my method’s depending on the requirements of the project.