Question

Zero-D

Everybody starts using CSS with a single file that contains all the styles.

• style.css

1D

Soon it becomes bulky and one decides to group CSS in a number of files by page elements:

• html_elements.css
• header.css
• main-area.css
• footer.css

Some may find this not convenient enough and group styles by function:

• typography.css
• layout.css
• sticky-footer.css (contains declarations for many elements, not footer only)

2D

When a project has a lot of CSS, it might require using both groupings simultaneously. CSS files structure becomes two-dimensional:

layout/

• grid-system.css
• header.css
• sidebars.css

look/

• typography/
  • main.css
  • headers.css
  • lists.css
• backgrounds/
  • html_elements.css
  • header.css
  • main-area.css
  • footer.css

Okay, the example is fabricated, but you sure do understand what i mean.

Up to this point everything is fine.

Enter Media Query

This is where my CSS structure gets funked up.

In addition to the 2D structure described above, i have to structure my code by media queries:

• Some of my styles are universal (applied everywhere)
• Some are applied to certain screen size only:
  • small;
  • medium;
  • large;
  • extra large.
• Some are applied to certain groups of screen sizes:
  • everything except small (non-mobile styles);
  • small and medium (where sidebars aren’t at the sides)
  • large and xlarge (where you do have sidebars)

I tried to overcome the issue by scattering media queried styles among existing CSS files. The breakpoint Compass extension helps a lot, but the stylesheets become too messy. Finding a certain style when it’s not portrayed in the files structures a lot of pain.

I tried grouping by media queries, then by elements and function. But files structure is two dimensional, so you can’t add a new dimension, you can only add another level of hierarchy. So, it’s not graceful. Also, it’s very bulky.

So i end up with a 2D structure with media queries on one axis and an ugly mix of elements and functions on the other axis.

I’m absolutely not satisfied with that but i just fail to come up with a graceful solution. Please suggest one.

Answer 1

CSS is already a structured language. For better or worse, the order of your code changes it’s meaning. Because of that, it’s important that any CSS organization scheme is dictated primarily by the cascade. The other structural aspect of CSS is semantics. Use it to your advantage. The concern of organization is keeping things meaningful and maintainable. The best thing you can do to retain meaning is to show relationships. Relationships are already expressed by semantics.

Put those things together, and you end up with code organized by specificity first and then semantics, but never by external concepts such as type vs. layout or screen-size. Here’s my naming scheme:

base/
  - Sass imports and settings - no CSS output.
  - e.g _grid, _colors, _rhythm, etc.
general/
  - Initial CSS baseline with resets, defaults, font imports, and classes to extend.
  - e.g. _reset, _root, _fonts, _icons, _defaults, etc.
layout/
  - The rough outline of the site structure.
  - Not "layout" as a set of properties excluding type, "layout" as the overall site template which might well include typography. 
  - e.g. _banner, _nav, _main, _contentinfo, etc.
modules/
  - All the details. First by effect (classes/general), then by widget (ids/specifics).
  - e.g. _users, _admin, _product-lists etc.

Media-queries should stay as close as possible to the code they affect. When possible, they go directly inline (with Sass media bubbling). If that becomes bulky, they move outside the block, but never outside the partial. MQ’s are overrides. When you override code, it is especially important that you are able to see exactly what is being overridden.

On some sites, you may take this structure farther. I’ve occasionally added two folders at the end: plugins/ to manage 3rd-party code, and overrides/ to handle unavoidable (try to avoid them!) location-specific overrides to a widget. I’ve also gone deeper, adding a fonts/ folder with partials for each font family, or a users/ folder with partials for adding, editing, viewing, etc. The specifics are flexible, but the basic organization remains the same:

• Start general.
• Move towards specifics as slowly as possible.
• Never divide based on any external concepts (type/layout, screen-sizes, etc).