Ask HN: Anyone have a really smart way to organize css?

I'm hoping for some good answers here, because I'd love a better way.

I always put universal elements first (body, img, @font-face, etc.), then I just organize it top to bottom by page location (i.e. header, content, sidebar, footer, etc.). I also tab-indent so that elements within another are indented and "contained" underneath, making it easy for me to move from one section to the next. I also write the CSS horizontally, only making a new line for a new element.

I should also note that I'm a n00b :-), so this could be a horrible way to do it.

I do it by widget and layout.

Slightly related, but mainly a formatting issue, I format my css files as such:

  .foo    { x: y; a: b }
  .bar    { m: n }
  .baz    { background: blah blah url(xyz.png) top left;
            x: y; i: j; }

instead of the more commonly seen:

  .foo {
    x: y;
    a: b;
  }

  .bar {
    m: n
  }

  .baz { 
    background: blah blah url(xyz.png) top left;
    x: y; 
    i: j; 
  }

My format takes up less vertical space in the editor. Sometimes, I can get my entire CSS file into a single page on the screen, reducing the amount of time I spend scrolling and searching. I do split lines when they go off the edge of the space, as seen in the .baz example.

To be honest. With firebug's ability to tell me what line and css files the style on an element is coming from I don't find spending a lot of time on organization to have a ton of benefit.

I haven't used it, as there just hasn't been a project with enough lead time to experiment with something lately, but I'm fond of the idea of code generators for CSS, like CleverCSS for Python and Sass for Ruby.

Other than that, the best advice I can offer that I DO follow is that I group all HTML elements together, all IDs together, and then all classes together. Within each of those groupings, everything is in alphabetical order.

  body { foo: bar; }
  form { foo: bar; }
  h1, h2, h3 { foo: bar; }
  input { foo: bar; }
  p { foo: bar; }

  #container {}
  #footer {}
  #nav {}

  .etc {}
  .even {}
  .odd {}

and so forth.

I have four core files:

    reset.css    - I use eric meyer's
    elements.css - Global defaults for things like body,
                   h1, h2, h3, p, a, input, strong. All
                   or almost all selectors in here are
                   just tag names.
    layout.css   - Just sets up the global layout with
                   containers: e.g. header, footer, left
                   column, right column.
    blocks.css   - Reusable chunks.

In addition to that, I use a separate file for each "page type". For example, 'article.css', 'index.css', stuff like that. Some larger sites merit additional files like splitting off 'forms.css', 'tabular.css', etc.

All files get concatenated and minified before serving, obviously.

Use SASS with partials and mixins and sort them as it's more convenient for you (probably following the natural flow of descending order of your page).

I leverage SASS and Compass for Ruby heavily.

I utilize mixins heavily so I can modulize all my styling and make sure it's included in areas that are appropriate. I've learned this is the only way to handle CSS without styles getting too complicated and accidentally changing something where you didn't mean to.

Example (create a mixin that has certain styles for forms and then include it in a body.wizard page) this way I keep my CSS very dry.

General coding guidelines are horizontal. I recently switched to this. I used to do vertical and indentation but it's very hard to read with big files. I've found that it's a lot easier to read horizontal CSS.

I alpha all my styles from a-z.

LESS CSS seems worth a look: http://lesscss.org/

i saw one guy's css once it it looks like:

  .wrapper { ... }
      .sidebar { ... }
      .content { ... }

the indentation was well done.

Here's what I do:

- Almost all CSS goes in 1 big file. One line per selector to keep thinks clean and easy to find. Styles from external sources (like jQuery UI) go in separate files.

- Reset lines go at the top, if you use them, in a / RESET / section.

- Styles for individual HTML tags are next in the / HTML TAGS / section.

- Then a / UTILITY CLASSES / section for clearing floats, etc.

- Next comes site layout. Headers, footers, page width, etc. all go here. Just the layout though - think the grid. No real content styling yet.

- Now sections for each piece in the layout. Content styles go here. First a section for the / HEADER CONTENT /, then a big section for the / PAGE CONTENT / (vast majority of styles go here), then the / FOOTER CONTENT / styles.

The best suggestion I can give is to break up your CSS into multiple files. If you have a "projects" page, make a "projects" CSS file for style definitions specific to that page. I keep the overall layout elements together. I typically also have a "forms" CSS file just for buttons, form layouts, and inputs.

Then @import everything in screen.css.

Natalie Downe, my co-founder, has a very neat technique for organising CSS which she calls a CSS System. She described it in this talk:

http://lanyrd.com/2008/barcamp-london-5/sg/

She splits everything in to general styles (basic HTML elements), helper styles (things like forms, notifications, icons), page structure (header, footer, layout columns etc), page components (reusable composable classes for components that occur on different pages in different combinations, such as a news teaser) and over-rides (special cases for individual pages, rarely used).

She hardly ever uses IDs, preferring classes for almost everything - because CSS written against classes can be used more than once on a page.

She uses CSSEdit's groups feature to make the CSS easier to navigate - it's all in one file. http://macrabbit.com/cssedit/

View the stylesheets on http://lanyrd.com/ and follow the link at the top to the unminified version to see annotated examples.

After many years doing CSS my best workflow has come to this:

    reset.css //for resetting browsers
    grid.css //if I'm using a css framework
    global.css //styles that are shared across the site
    section.css //styles that pertain a specific section. The name of the file varies, i.e. "about.css".

You need a good code editor that allows you to open files without tabbing or reaching for the mouse, I use Textmate's Command T to switch fast among my files.

reset.css There's a bunch around, I use the one from htmlboilerplate.com, but there's many good ones available. (Eric Meyer's). You will almost never touch this file.

grid.css I only use this occasionally, when I'm working on sites where the grid is very clear and I take out all the stuff I'm not going to use. I usually go for a three col version of 960.gs and trim it to about 12 lines of css. Never touch this.

global.css Here you put your nav, your footer, you body styles, etc. I think that separating by colors and typography doesn't make sense, because you usually change a widget's appearance.

section.css I count on the body tag having a classname, so I can have body class="about" and then do...

    .about section.photo {...}

This way you never override your styles accidentally.

Miscellaneous I avoid the one declaration per line convention when I have similar styles and I want to be able to read them in a table format, i.e.

    .available {background-color: #0f0;}
    .taken     {background-color: #00f;}
    .deleted   {background-color: #f00;}

I usually start from the most generic to the more specific, but I don't worry too much about code order because in the end I just do a search and reach it in no time.

A good example of some super organized CSS is in the HTML5 Boilerplate by Paul Irish. Found here: https://github.com/paulirish/html5-boilerplate/blob/master/c... I sometimes use multiple instances of the same selector, especially if a project starts getting very big. I like to separate each function of the site into it's own block after the footer declarations. It lets me stay organized during development and ensures that I can keep track of what I'm working on while I'm working on it. Here's the order I'm currently using, which was inspired by the above:

    /* HTML STRUCTURE STYLES */
    body { foo: bar; }
    h1 { foo: bar; }
    a { foo: bar; }
    /* Image Replacement & Hacks */
    .ir { foo: bar; }
    /* Container Styles */
    #header { foo: bar; }
    #main { foo: bar; }
    #footer { foo: bar; }
    .column { foo: bar; }
    .sidebar { foo: bar; }
    .img-cotainer { foo: bar; }
    /* Everything inside of #header */
    .navigation { foo: bar; }
    #header li.nav { foo: bar; }
    /* Everything inside of #main */
    .content { foo: bar; }
    /* Everything inside of #footer */
    .social { foo: bar; }
    #footer li.nav { foo: bar; }
    /* Everything in specific view inside of a container from above */
    .profile { foo: bar; }
    .comments { foo: bar; }
    /* Media Queries */
    @media all and (orientation:portrait {
      * { foo: bar; }
    }
    /* Print Styles using Media Query */
    @media print {
      * { foo: bar; }
    }

For me the biggest goal is fewer lines to organize in the first place rather than any particular scheme for grouping. What I do is:

1) Use as few separate stylesheets site-wide as possible so any contradicting or repetitive rules will be obvious.

2) Use one line per rule so I can scan the selectors quickly, then scroll horizontally if necessary

3) I prefer complex comma-separated selectors which set one or two properties to simple selectors which set many properties. Grouping in this way gets me closer to having constants, e.g. a specific hex color won't be rewritten again and again, it will just follow a complex selector list.

4) Once a selector works, I try to make it more general, e.g. "div.info { font-size: 12px }" can probably just be ".info { font-size: 12px }". More general rules will apply in more cases, so fewer overall rules will be necessary.

On an MVC site, I organize by controller. There's one general file for generic cross-site stuff (header/footer, etc.), supplemented by another CSS file that shares the markup for all controller-specific pages.

This gives a max of two css files per page. For the landing page I compress the generic file along with the controller-specific css file for the default page into a single file. This speeds up the loading process while preventing too much bloat. Since the other pages are usually hit after the landing page they require only a single extra download. Any reset code can be included in there as well, although maintained as a separate file.

I doubt this approach is ideal when it comes to organizing things, but it's fairly fast when it comes to development. I design by including css in style="" and then refactoring the markup into classes once the design is complete. Saves a lot of back and forth while getting things lined up.

  %body(class="#{controller.controller_name} #{controller.action_name}")

  <body class ='<%= "#{controller.controller_name} #{controller.action_name}"%>'>

I've really enjoyed SASS/SCSS optionally with Compass. It lets you compile the stylesheets while still keeping the source files separate and organized. I've also seen the approach with one big file for the application with commented sections, however, the drawback to that approach is using a version control system with multiple editors on a large file (merge conflicts, etc).

Start by using sass reset.sass 960gs.sass default.sass In default @include reset and 960gs (sass compiles it all into one css file)

Then use a per page sass file that references default.sass

If you want something pre-built that does all this use compass.

At some point, the amount of CSS complexity becomes best handled by a preprocessor.

Stylus is great: http://learnboost.github.com/stylus/

I made a post about it, and personally prefer it to Sass and Less: http://nylira.com/stylus-the-revolutionary-successor-to-css/ The hardcore abbreviation mixins in my post seem to offend some coders. When you work in CSS and HTML hours every day though, every character saved adds up to a huge productivity boost.

My current project has 30 directories with 73 partial Sass files, which compile down to one 320kb file.

As to your question, I organize my partials based on controller and url structure.

I just use Blueprint.

Lots of comments really help, especially when you look at it months after.

Suprised no-one has mentioned Nicole Sullivan's (amongst others) Object Oriented CSS (OOCSS) project: https://github.com/stubbornella/oocss/wiki

She used this approach at Facebook (and Yahoo, I think?) to successfully tidy up a huge code base of thousands of CSS files down to a more manageable few.

I attended her workshop at Webstock and since then had a chance to put it into practice on a 'get it up quick' green fields project (http://chchneeds.org.nz). I must say I was really pleasantly surprised at the way this approach just avoids a lot of the pain points, as a web developer/coder (ie not an html/css guru) I so often face when just getting the simplest things to 'work'.

I guess the hardest thing for me to get my head around to was that to make things more modular you had to let go (a tiny bit) of being so religious about 'semantic html' as a requirement for the HTML, but I think its worth it to get your CSS a whole lot more modular and 'pluggable' together.

Still a bit more work to do, IMHO, but I'm definitely going to be monitoring this project closely.

Nicole Sullivan's site: http://www.stubbornella.org/content/

I once tried breaking my css into files according to function (typography.css, color.css, layout.css). It ended up being a royal pain because when I added a new HTML element and I went to style it, I ended up having to duplicate the css selector for that element in three files. I also was constantly switching among the three files to work with one element's styles. So whatever you do, don't organize by function. :)

Ever since using Drupal's Zen theme I have preferred their basic setup for grouping CSS files. Here is a rough example:

html-reset.css layout-fixed.css page-backgrounds.css messages.css pages.css blocks.css navigation.css comments.css forms.css fields.css print.css ie.css ie6.css

Drupal's CSS optimization, once turned on, will roll all of these up for you automatically, so if you aren't using Drupal you will need some sort of build system to combine and minimize everything. But I think this is a good start.

On a side note, I really like the method the Zen theme uses for CSS columns. Worth checking that out as well.