Structuring CSS

Lots of Little Files
Scrolling through huge css files is slow and painful. Using ctrl-F, an editor that supports tag folding and/or using one class per line formatting can help, but we've all learnt from programming that putting all of your code in one file isn't ideal. Apart from more scroll time, it also makes modular re-use harder and increases the cognitive load when working with the files.

Of course, when you deploy a website, you only want a small number of CSS files (one or at most a few) to cut down on the number of http requests required to serve the page, but that has nothing to do with how you work with the files. Ant, Make, Rake - build tools were designed for these kind of tasks. Don't make your development code base harder to work with just to simplify your build processes. Automate your builds and segment your CSS.

Semantic CSS is Worth The Effort
I've tried to love Blueprint, YUI Grids and other similar grid based frameworks, I really have. I didn't want to have to mess with resets and browser incompatibilities and I think that for prototyping sites, such frameworks are great.

However, I really don't like describing my grid layout in the HTML. For example, in a recent blueprint based site (the site rocked, BTW) I saw the following snippets of code:

To me this a perfect example of what CSS should NOT be doing. I love the idea of CSS frameworks, but I think a grid based approach is a retrograde step. Is it just me or does that simply look like a tighter way of putting font tags into the code with all of the layout information in the div names? I'd be open to a web based generator where you drag, drop and position your divs, give them semantic names and then it generates the appropriate CSS to implement that grid automagically while still leaving you with fairly presentation free HTML, but I'm not comfortable for production applications to have so much layout information in my HTML.

I should be able to completely change the layout of my site without touching the HTML - whether for skinning or other purposes, and I just don't think the grid based frameworks are solving that problem optimally at the moment. I must clarify, this is not a knock on frameworks. I actually have thoughts about exactly how to solve the problem - I just don't like the current implementations from a separation of concerns (content in HTML, layout in CSS) perspective.

Site Wide vs. Screen Specific
It seems to me that one of the first distinctions for breaking up css is between site wide concerns (everything from the overall structure of the pages to the default styles for an H1 or an input element) and screen specific concerns that relate to one or more specific screens but not to the rest of the site (elements specific to a shopping cart or an article list). When I develop content management systems, each site can have n-site wide layouts (sometimes a home page or another section will have a unique structure) and then content areas are comprised of one or more composed screens (cart display, order list, user detail, etc.) so at least for my use case it makes sense for me to use this as a starting point to drive my CSS segmentation.

Additional Distinctions
Of course, there are a number of other ways of breaking up your CSS. You might want a utility CSS file for handling general browser incompatiblities (some kind of reset - CSS). You might want to have a forms library, a tables library, to distinguish typography from block/layout elements and so on. I've seen a lot of different suggested approaches to this, and I'm probably going to just play with a few and see what works for me.

Skinning Sites
One of the more interesting challenges is how to write good skinnable CSS. Usually skins will affect colors (including background colors), images, font faces, sizes and colors. They could also affect form styling, table styles, bullet styles (in different ways in different parts of the site/page) and a number of other elements. In an extreme example, a skin could completely change the layout of a site, but often skins want to be user editable via some kind of forms based interface, so the ideal skinning solution would allow for reuse of standard styles so creating a new skin wouldn't require you to define everything but would allow you to overload a certain subset of the style rules.

It seems to me there are three general approaches to skinning: overloading, variables and/or multi-style elements.

Skinning Through Overloading
One flexible/lightweight approach to skinning would be including the appropriate skin CSS at the bottom of every CSS file. The benefit of this is that you'd have a default style for the site and then each skin would only have to overload as many of the style elements as needed to be changed (obviously the skin CSS would be a separate file and would just get merged as part of your build).

Skinning Through Variables
The problem with skinning through overloading is that you often have things like colors which are repeated in many places. If you have a number of different styles that should all be in the "secondary palette color", you can try to implement that through visual inheritance (the Cascading in CSS), but you often come across issues where this is either impossible or makes for a very unwieldy structure. I can imagine wanting my H2's and table borders to share the same "primary accent style", and doing that in CSS while being DRY (not typing the color twice) isn't easy (see option 3 below for one possibility).

The obvious way to solve this problem would just be to put variables into your style sheets. In that way you can just set color: %Accent_Color% and write a build script and/or production generator code to create the appropriate stylesheets for appropriate skins. This could be a pain to code if you took a heavy handed approach to writing the generator, but if you just wrote a script to look for all of the variable names in the style sheets and then auto-generated a form for creating skins using all of those styles, it'd be fairly lightweight. You'd probably just have to use some kind of convention so that (for example) the last word drove the type of form field (whether to provide a color picker, a font drop down and so on). The only minor issue is if you add a new variable to the style sheet you're going to have to decide what to do about all of the old skins that don't yet have a value for that variable. It's the same kind of issue you get whenever you evolve the grammar for a Domain Specific Language (which is what adding the extra variables is a very simple example of), but there are patterns for solving such problems.

Skinning Through Multiple Styles
Another possible approach would be to use the multiple styles technique that seems to be quite popular these days and that I learnt from Javier earlier this year at CF United when checking out his great form CSS. The basic principle is that you can apply more than one style to a given element (e.g. in the example code about where you had 'div class="column span-24 shady"'). So I could imagine naming a div 'div class="image secondary-accent"' where the secondary-accent would be the class that would set the secondary accent color. This solves the problem of re-use without needing a step to generate variables, but it seems to me to be starting to go back to presentational rather than content specific semantics. In short, it's a very cool trick, but I'm wondering if it leads to the dark side!!!

OK, I'd say that is enough to digest for now. Any input appreciated. I'll play with this and if I come up with anything worthwhile I'll be posting about it over the next couple of days.