SMICK.NET | Website of Mike Smick Graphics and Web Developer

Ways of organizing your CSS to achieve flow

Could you be writing your CSS better? I’ve been thinking about my project flow lately and noticed there’s a lot less flow and a lot more rework than there should be. I think that’s because I’m always trying new things. But I suffer the consequences of not establishing consistency and clarity. In this post, I’m talking specifically about how you wire up your main CSS file. When I talk about organization here, I’m talking about categories inside that css, so it’s easy to traverse. I firmly believe it can help speed up development and improve everything.

CSS Comments

This is how you can create categories. Write CSS comments out so they visually look like category headers.  Example:

/* ========   This is a Category Separator CSS comment   ========= */

Everything under this comment would be idenfied with it as a category.  I’ve made a lot of variations on this type of header. I’m not sure what  you like but using special characters appears to work well. I like Equals signs because they create a thick obvious border.

Categorize by function

What are the bits of CSS affecting?  Consider that if you are covering font changes, you can group all your typography under one header. So when you make a font change, presumably that section will be easy to find and less stuff to read through. Same for layout. Are you changing the padding for one or more divs? Put it under the Layout / Div category.

/* ========   Reset (if applicable)   ========= */

/* ========   Colors   ========= */

/* ========   Typography   ========= */

/* ========   Layout / Div   ========= */

/* ========   Misc classes   ========= */

Categorize by task / override

CSS means Cascading Style Sheet. The cascade is like the waterfall down a multi-level rock formation. The code described at the top, falls all the way down. So the global rules you put at the top. Underneath that, you continue with the exceptions to the rule, going from genral to specific. You can think of this and how your project is built. The template will have some standard things, and trickle down to the very specific. Some changes might only occur on specific pages, while others only occur in a single spot on one page and never again.

/* ========  Base (styles every page)   ========= */

Things like the menu bar, the header maybe (unless it will change in appearance leveraging CSS)

/* ========   Site Section Level changes   ========= */

/* ========   Specific Page Styles or Overrides   ========= */

/* ========   Occasional Styling   ========= */

/* ========   Minutiae (could almost be used inline but decidedly better here)   ========= */

Categorize By Visual Areas

This one is really common for me, but I grow it organically for each project rather than commit to specific labels each time. I’m not necessarily sure how not to do this in some respect on projects because my brain thinks this way.

/* ========  Body  (A few type or color global values )  ========= */

/* ========  Header  ========= */

/* ========  Navigation Menu  ========= */

/* ========  Content / Main  ========= */

/* ========  Gallery  ========= */

/* ========  Sidebar  ========= */

/* ========  Footer  ========= */

/* ========  Misc. or further addendum ========= */

I just want to point out this last Misc. section I also would add things like classes that the WYSIWYG editor uses.

Collaborating with Others

If you work alone, you benefit from being able to drive standards 100%. If you work with others, you want to best conform but also to discuss and agree to ways to do projects. Mostly it will come down to cross-training.  A lot of developers do quick and dirty CSS while fixing the widget they are working on and unfortunately never go back to clean it up.  This behavior will go on and it just needs to be repeatedly trained.  Ongoing project improvements and maintenance require some attention to details.  When you put things in categories a benefit you’ll find is eliminating redundancy. When everyone is referring to the same codeblock of CSS for edits to the base or header or typography, there’s a good chance they will see the previous entry for that class so it won’t be repeated.

When you work in a version control system you can see who added what to the code, but whether or not that’s the case, consider this. Some changes might be best identified near the code itself.  Let me give a quick scenario.  Let’s say you are a 3rd party agency taking on a new section of the site.  Your front end dev may not have a couple days to get a full understanding of the site, and all the current or outdated pages under the hood. Your task might be to build a certain landing page page in the CMS. If you have say 4 hours to work on something while the main developer is on leave. Instead of meddling with the code, create your own section.  If it happens to break some outdated legal page, at least your code is easy to find.

/* ========  Edits by Open Ground Co (for x landing page 11.30.2013) ========= */

Another variation on this, if you happen to need to make a fix to an existing line, consider a quick comment after it:

.classname {padding-left:-1.2em; }  /* == OG edit 11.30.2013 == */

These variations and tips are attempting to say the same thing: “Begin with the end in mind.”

December 1, 2013 at 12:36 pm | computers, CSS, design, freelance, Front End Development, graphics, webdev | No comment