WordPress CSS Setup

A few people, like Chris Coyier and Tom Mcfarlin, are writing posts about how they setup their CSS for WordPress theme development, so here’s my take.

Directory Structure

For any front end development, I always have a CSS folder, and WordPress is no different. Just because WordPress requires a commented style.css in the root of your theme, doesn’t mean that needs to be your main CSS file. I leave that file for WordPress recognition, then in my header.php enqueue my main style (see below) in my CSS directory. I also leave a minified version of the style declared below that to easily switch back and forth from production to development.

Enqueue Example


<?php
wp_enqueue_style( 'styleDev', get_template_directory_uri().'/css/style.css', '', '1.0' );
//wp_enqueue_style( 'style', get_template_directory_uri().'/css/style.min.css', '', '1.0' ); 
?>

File Structure

I use Sass as a preprocessor and have Codekit compile my code for me. I have Codekit to output the CSS in the parent directory of the .scss file. Keeping all the CSS and SCSS files I need in one directory makes it easier to get what I need.

Next, the structure of my main style.scss file is setup for mobile first development. I found scrolling through large CSS files to be inefficient, so breaking out each media query makes things more navigable.

style.scss


@import 'mixins';
@import 'wordpress';

//Base Styles
@import 'base';

//Mobile First CSS
@import 'media320';

/* ===MEDIA QUERIES START=== */

@media only screen and (min-width: 768px) { 

    @import 'media768';

}

@media only screen and (min-width: 1024px) { 

    @import 'media1024';

}

@media only screen and (min-width: 1200px) { 

    @import 'media1200';

}

@media only print { 
  * { background: transparent !important; color: black !important; text-shadow: none !important; filter: none !important; -ms-filter: none !important; }
  .header, .footer, .sidebar, img, form { display: none !important; }
  #container, .content, .content-main { width:100%; padding: 0; margin: 0; }
  a { text-decoration: underline; }
  pre, blockquote, tr, h2, h3 { page-break-inside: avoid; }
  p, h2, h3 { orphans: 3; widows: 3; }
}

//Helper classes
@import 'utility';

I addition to the media query includes, I also break out _utility, _base, _mixins, and _wordpress files.

The _utility files houses a collection of utility classes that I rarely if ever edit, so it seems pointless to include them in a file I actively work on. Some of the classes include clearfix, image replacement, floats, hides and visual hides.

Next, and maybe the most important is the _base include. This file houses all my base styles as well as any low level classes that are used again and again through my css.

Finally there is a _wordpress include with some WordPress specific styles like .aligncetner, .alignleft, etc as well as gallery styles. If a site requires these styles to be more flesh out I’d add them to another file, but they’re here just in case. Breaking these out makes it easier to use the same CSS system for use on other platforms like Drupal or Magento.

Other Compiled Files

I have two other compiled files that I use. The first is a wysiwyg.scss file that includes _base, as well as some other rules. This file is used for WordPress WYSIWYG in the backend, and I already have the function in my function.php pointing to this file.

wysiwyg.scss


@import 'mixins';
@import 'base';

body    { font-size: 16px; background: none; }

And finally, my ie.scss file. This file includes all the non mobile first media query includes and compiles them outside of their respective media queries. This is in place for older version of IE that do not understand media queries. I typically only serve these users up to the 1024 view. Again in my header.php file I already have a lte IE 8 conditional stylesheet in place pointing to this file.

ie.scss


@import 'mixins';
@import 'media768';
@import 'media1024';

So that all of it! It seems like a lot but by making things more modular, its makes maintenance a lot easier. You can find all these files as well as my boilerplate WordPress theme in my Site Skeleton.

posted in: Front End Development, WordPress
tagged: , ,

3 Comments
  1. Tom McFarlin

    Just because WordPress requires a commented style.css in the root of your theme, doesn’t mean that needs to be your main CSS file

    Definitely agree here.

    In my most recent work, I’ve stopped populating my style.css file with everything but the required headers. I’ve toyed with treating that file like a manifest and using import to bring in certain dependencies, but I’m a much bigger fan of doing it on the server-side for the sake of speed and tailoring the imported files on an as-needed basis.

    Dug this post – I like seeing how the rest of you guys structure your work.

  2. Brian Krogsgard

    Nice post! This and Tom’s post both have me leaning toward using Style.css as little more than a home base as well. Especially if the site isn’t min-width media queries, and all of them are loaded after the main styles, changing responsive styles in a child theme is a pain. It’d be much easier with separate enqueues for separate files.

    Thanks for the inspiration and getting me thinking!

  3. Hassan

    I use Gantry and in Gantry, all CSS goes to /css folder and the style.css file is used only for it’s required headers. But one thing that later on bites me in my back is that the theme editor in WordPress pretty much sucks and cannot find these css files, so editing these live would be impossible.
    BTW, I find this snippet very useful when I need to switch between development and production stylesheets: http://justintadlock.com/archives/2010/09/29/development-stylesheets-for-theme-developers