How to structure your css.

This is not to say this is the perfect way to work. But it's the way I've been working for years and has really helped me. Inspired by others and by the book SMACSS.

Thinking in modules.

Modular design for me means to separate logical pieces of code for maintainability and reuse.

If everything you do is in one big file, no comments or anything separating parts, all code is very specific and cannot be easily re-used, then it'll be difficult to maintain.

Working in modules you'll find you work faster and more precisely: you'll become a ninja at making quick changes for the client and the client will love you, or at least you'll be happier with your own code.

Example time:

Here's some CSS maybe you've written before. Some text node colors, some buttons have a fancy style (I'll call that fancy-button for later), some text content areas with minor changes between them and a couple minor tweaks on a larger screen.

This will be a long code example but feel free to comment if you have any questions about it/

Original code / what not to do:

# File: site.css

h1 { color: #444444; }  
h2 { color: #444444; }  
h3 { color: #444444; }  
p { color: #000000; }

.header-search .button {
    background: orange;
    color: #FFF;
    padding: 1em;
}
.sidebar-filter #submit-button {
    background: orange;
    color: #FFF;
font-size: 20px;  
    padding: 1em;
}
#contact-form-button {
    padding: 1em;
}
.home-page-content {
  padding: 1em;
  *padding: 15px;
  border-top: 5px solid red;
}
.home-page-content h1 {
   color: red;
}
.about-page-content {
  padding: 1em;
  *padding: 15px;
 border-top: 5px solid blue;
}
.about-page-content h1{
color: blue;  
}

@media screen and (min-width: 35.5em) {
  h1, h2, h3 {
    border-bottom: 1px solid #CCC;
  }
  .home-page-content {
    margin: 0 1em;
  }
  .about-page-content {
    margin: 0 1em;
  }
}

To me, you can work with it, but it's not ideal, and as that grows it will get unmanageable. Lets separate it out to more modular files: (The following files would be included/imported into your site.css file)
I'll comment above each part with the file name, and then under it will be notes on what changed and why its better.

# File: base.css

/* ===== Base styles for site ===== */

/* --- main font colors --- */
h1,  
h2,  
h3 {  
    color: #444;
}
p {  
    color: #000;
}

/* --- default button style --- */
button,  
input[type="button"],  
input[type="submit"],  
.button {
    padding: 1em;
}

/* first breakpoint */
@media screen and (min-width: 35.5em) {
    h1,
    h2,
    h3 {
        /* add a clean border under headings */
        border-bottom: 1px solid #CCC;
    }
}

The above shows base styles for making the page, e.g. fonts, button styles etc..
Separating out the base styles like this helps you quickly find default style applied to all elements. It should be fairly simple, anything more complex should be it's own module or layout file.

# File: modules/fancy-button.css

/* ===== fancier designed buttons ===== */

.fancy-button {
    background: orange;
    color: #FFF;
}

/* --- fancy button mods --- */

/* larger text version (could be abstracted further) */
.fancy-button-large {
    font-size: 160%;
}

This module for the fancy-buttons assumes you have access to change the HTML, if that's not the case you could make the same module file, but instead of .fancy-button and .fancy-button-large you can comma separate the selectors like so:

/* ===== fancier designed buttons ===== */

.header-search .button,
#submit-button {
    background: orange;
    color: #FFF;
}

/* --- fancy button mods --- */

/* larger text version (could be abstracted further) */
#contact-form-button {
    font-size: 160%;
}

This keeps it modular in it's design, it's only the name of the selectors used that isn't as organised so that's still awesome.

Also notice .sidebar-filter #submit-button has been changed to #submit-button as an ID should be unique and the class prefix is therefore redundant.

# File: modules/page-content.css

/* ===== Page content areas styling ===== */

.page-content {
    border-top: 5px solid;
    padding: 1em;
    *padding: 15px; /* slight IE hack needed to account for a margin bug */
}

@media screen and (min-width: 35.5em) {
    .page-content {
        /* space out the content a bit when available */
        margin: 1em;
    }
}

This offers a generic module for page content, which could quickly be applied to all pages without need for copy and paste. As the design grows, this would be much more important.

# File: pages.css

/* ===== Specific page mods ===== */

/* --- home page (red theme) --- */

.home-page-content {
    border-top-color: red;
}
.home-page-content h1 {
    color: red;
}

/* --- about page (blue theme) --- */

.about-page-content {
    border-top-color: blue;
}
.about-page-content h1{
    color: blue;
}

This layout file for specific pages offers per page differences, which are now very minor and get down to exactly what is different, making maintaining and debugging much easier.

Once you've written your code like this, go back over and review it. Spending a little time re-reading, improving and re-factoring your own code is worth it. You'll learn more about the way you write code, patterns you could reuse.
Using dev tools, you can look over some of your code too, specifically you can inspect the elements you've been working on and view the style tab. Here if you see that code is being overridden a lot of the time with large amounts crossed out then you could probably re-write the code, or re-think the way that element works and the css modules you have selectors to it.

Check out these resources on truly making your css skills awesome!

• https://smacss.com/book/
• http://maintainablecss.com/

Also I've previously wrote about a reading list for modern web design.

Some best practices to take away.

• Think in modules.
• Take pride in your code, format it well.
• Understand what your code does and why and avoid magic.
• Use comments and files to organise code and additional comments to explain why some things are needed.
• Avoid specific browser hacks.

My closing comment is: invest in your knowledge now, your future self will thank you.

If you have any questions? Or found a bug ;), please leave me a comment and I'll try to reply as quick as I can.

"CSS is quick to learn, but takes years to master".
- Not sure where I first read this but it's still true today.

It's difficult to give years of experience as training. People expect designers to know things after a day of training that you'd normally learn with months or years of experience. Some patterns I'll talk about in this post only reveal themselves as bad decisions later on. The best I can do is show you mistakes I've made, and other designers have made. Hopefully you can learn from where we went wrong ;).

Anti-patterns.

Anti-patterns explained: What not to do and why.
Found something controversial? Leave me a comment and we can discuss it further :).

1. Avoid separating styles for the same things.

A case of this I've seen before is separating into different device groups, e.g. mobile.css, tablet.css, desktop.css.
Similar used to be done on sites with a ie7.css file etc.

On the face of it, it sounds like a good idea. Everything is separated out, but it's separated in the wrong way and ultimately it's a naive approach. It often encourages duplication because the blocks of style are separated. This makes it difficult to track down specific styles for an element as they then span multiple files, which often ends in code being copied for each file as it's forgotten it's already set and inherited.

Instead my advice is to build specific module css files, we'll come back to how you do this later in the post.

2. Don't copy paste chunks of code.

This one seems obvious when thinking about most coding languages, but maybe not so with your css.
While working on your css, think about how some styles can be joined together. Remember you can join css selectors with commas so code such as:

.banner p {
  margin: 0 0.5em;
  color: #222;
}
.banner h3 {
  margin: 0 0.5em;
  color: #444;
}

Can become this, which is much easier to maintain and keep consistent:

/* ===== Banner module ===== */
.banner h3,
.banner p {
  margin: 0 0.5em;
}
.banner p {
  color: #222;
}
.banner h3 {
  color: #444;
}

Yes the above code is longer but maintainability is what we are aiming for.

3. Avoid naming classes just by their current properties

Such as .red, because what is red? Will it always be red, what if we change to green... Do we go round everywhere changing the class name to green, or do we change the property and will red now mean green.
Ok this one seems obvious especially with my example, but often when designing more modular css you can get carried away and go too abstract to the point of classes for everything like .red, .font-serif, .text-align-right which leads to even worse code.

Instead, try to think of what the element is, such as a block on the sidebar for latest news. you could have a module called .latest-news, but then you could go further and make that a generic .sidebar-block which can be reused for all your sidebar blocks. On top of this you could then still have .latest-news or .sidebar-block-latest-news for specific extra changes on top of the default .sidebar-block, but consider how this could be shared with other blocks on the page too.

4. Don't just slap !important on it ;)

I find !important is very rarely needed, but too often designers try a selector, find it doesn't work and is somewhere overridden. So they give up and slap an !important on it.
Learn about how selectors and inheritance works!

The topic of CSS specificity deserves its own post, luckily there's several out there that do great jobs. Specificity Wars is a fun introduction to it, along with articles on CSS-Tricks, Smashing Magazine and the Mozilla Developer Network

Tools such as Specificity Calculator are also helpful for you to work out why a selector is more specific.

If you don't bother to learn about it, you'll be forever doomed to fight your forest fire of !importants later.

5. Read the source code!

While you're working in systems or you have build scripts that generate a main/master css file from all your other files, don't be afraid to jump in and take a look to work out why an issue is happening or to check your code is being built the way you expect.
Systems sometimes also have to place some css in page, maybe because of their current module architectures, whatever the reason, if that's the system you work within, you'd better be confident you can find where some css comes from. (Luckily dev tools will tell you if css is from a file or on the page). CSS like this deserves care and attention to override. The source code wont lie to you.

6. Dev tools is your best friend, know it inside out!

Better than reading the source code (though that's still important) is using dev tools.

You need to learn dev tools for the browser you're working on. No two ways about it, go learn them now, at least the inspector :).
Here's a link for Chrome and Firefox.

The inspector will save you minutes, hours, days, weeks and more in trial and error.

7. Avoid fixing height & widths when you can.

This often happens when you have a mockup in photoshop and then you try to match the exact dimensions, which is great, except that this likely wont work as the screen size decreases.
Try to make your modules fluid, then they can fit into a grid or take the widths of the container. Patterns like this are core to responsive design.

8. Designing for desktop down or mobile up?

Instead try to think of mobile and up where you can. Often this will lead to simpler css breakpoints and less cruft around content. With this you can think about what's really needed in the design, without too much extra that on mobile wouldn't make sense.
Read more on Mobile First here, or check out Luke Wroblewski's Mobile First book

9. Clearfix the containers of your floats.

The clearfix class is somewhat magical, but really it's very simple. There's a few implimentations of it, but generally the practice involves adding a hidden pseudo element at the bottom of the content that clears the floats.
Sometimes you'll find this called ".clearfix", or ".cf".
Read more about one great example of this here

10. Avoid magic.

Maybe this seems weird when I just said clearfix is magic. But clearfix is simple when you understand how it works. Try to avoid code that seems to magically make things better if you don't understand why. Otherwise, how can you trust it will always work? How do you customize around it without breaking it?
Clearfix is a great example of this as if you did not understand how it works, you may try and add a pseudo element after it in your own css and find the clearfix no longer works.

11. Use the appropriate method for layout.

Often grids or inside blocks instead of floats for layout.
E.g. if you have 3 columns of evenly sized text next to each other, a grid is perfect. If you have a navigation list or boxes next to each other that are sized by their content, normal grids would be a terrible solution. Inline blocks are best for that as they are sized based on the content. If you have a title with a link to the right, float the link to the side, grids again are not really the best for that. There's no one way of doing things right, don't just follow one specific method, think about how it looks and what would really make the most sense. It may take a little longer to stop and think about each part. But if you do it will save you so many headaches later.

12. Don't style every thing as unique.

Try to reuse modules, again this is not to copy and paste, instead create a generic look for basic elements within content, and then create re-usable classes / modules for applying different styles.

13. Opt for relative measurements over fixed when you can.

Simple one, relative measurements such as em, %, rem etc. are more flexible and will often work better with your responsive design than px.
Not that you should cast aside px as a dirty relic, instead, consider the best measurement for the use case. Often in responsive design this will be relative measurements though.

14. Remember not all interactions require jQuery.

:hover, :active, :focus and more. Learn them, wield them like the awesome tools they are.

You probably already use these and know them well. But if you're working on something in javascript, it's easy to forget and use jquery or similar to do it instead.

15. Combine properties

Properties such as font and background can be combined. It's worth using the combined versions for simplicity such as:

background-color: rebeccapurple;  
background-image: url(/images/logo.png);  
background-repeat: no-repeat;  
background-position: top left;  

Could be:

background: rebeccapurple url(/images/logo.png) no-repeat top left;  

16. Avoid unnecessarily long selectors

Sure, referencing body #content .sidebar a works, but would .sidebar a work just as well?

17. Always test your ideas.

Developer tools allow us to test our ideas live, why wait to compile or ftp a file to a server to test your idea for a fix. Change it live in the developer tools and you'll have instant feedback.

18. Browser test too!

With complex modules, check ideas for them as you're going in browsers you think may be problematic, this will make things a lot easier when you return to fully browser check it later.

I've written more about browser testing here.

You can also use Can I Use... to find out browser support for new CSS properties etc. to find which browsers are likely problematic to start with.

19. Avoid specific browser hacks.

Try to find the cause of the problem, rather than a quick fix that may lead to further problems. You may find it's a problem in your CSS and you can work around a problem easier than just hacking it.
If you have to use a hack, explain why in a comment, make sure that in a month when you return to this project you'll know why you added it in.

20. Format your CSS in a clear and uniform way.

This one is a somewhat personal preference, but I try to always write CSS in the same way. I use 4 spaces for indentation (some people use tabs), I separate each selector onto a new line as I believe selectors are kind of the most important part of the css definition, and each property onto a new line.

You can see more of my style choices for CSS in the following post.

Can you expand this list past 20? Leave a comment with your own anti patterns or advice.

Enough with what not to do...

Continue to Part 2 for how to structure your CSS and more tips.

If you disagree with this list or do you have your own suggestions? Leave a comment below and I'll try to reply quickly.