How I write CSS (March 2016)

The way I write CSS changes, so I thought I’d record how I’m doing it right now so I can refer to it later, or possibly look back and laugh.


I’m still using BEM, although probably less now as BTB’s existing projects don’t make us of it, & it’d be odd of me to introduce a naming scheme to existing projects.

What I’m doing more and more is just using a hyphen. .box, .box-wrapper, .box-content, .box-title etc.


I love using SCSS, although setting it up annoys me. Currently at BTB we do this using a Gulp task, which I have a shortcut for in Sublime.

Nesting SCSS

I like using this notation so I don’t have to write out the component each time:

.feature-box {
   &__title {


   &__content {

Which renders to css as this:

.feature-box .feature-box__title { }
.feature-box .feature-box__content { }

This gets a bit complicated when you add a modifier to the component. Like a wide version (.feature-box–wide), as you have to do this:

.feature-box {
   &.feature-box--wide {
      //--have to do this bit separately

   &--wide & {

      &__title {


      &__content {

This uses the ampersand after a selector to select it’s parent, which is amazing (more about that here).

Media queries

I like to keep the breakpoints in variables, which makes them shorter, and easier to change in the future – not that I ever have! I just like it easier to type! (I also liked doing this in Bootstrap).

.feature-box {

   @media #{$medium-up} {

   @media #{$large-up} {

Adding the media query inside the component makes it easier to find too, as I like to group things together rather than chasing separate styles in another media query elsewhere.

Doing this means you need to declare these breakpoints as variables somewhere. I think I got these from Foundation:

$small-range: (0em, 40em);
$medium-range: (40.063em, 64em);
$large-range: (64.063em, 90em);
$xlarge-range: (90.063em, 120em);
$xxlarge-range: (120.063em, 99999999em);

$screen: "only screen";

$landscape: "#{$screen} and (orientation: landscape)";
$portrait: "#{$screen} and (orientation: portrait)";

$small-up: $screen;
$small-only: "#{$screen} and (max-width: #{upper-bound($small-range)})";

$medium-up: "#{$screen} and (min-width:#{lower-bound($medium-range)})";
$medium-only: "#{$screen} and (min-width:#{lower-bound($medium-range)}) and (max-width:#{upper-bound($medium-range)})";

$large-up: "#{$screen} and (min-width:#{lower-bound($large-range)})";
$large-only: "#{$screen} and (min-width:#{lower-bound($large-range)}) and (max-width:#{upper-bound($large-range)})";

$xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})";
$xlarge-only: "#{$screen} and (min-width:#{lower-bound($xlarge-range)}) and (max-width:#{upper-bound($xlarge-range)})";

$xxlarge-up: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)})";
$xxlarge-only: "#{$screen} and (min-width:#{lower-bound($xxlarge-range)}) and (max-width:#{upper-bound($xxlarge-range)})";

Because I’m using Foundation (still not preferring it to Bootstrap, but it’s growing on me) I’ve been using it’s own file structure, which is multiple sass files in a “components” folder.

REMs instead of PX

In my first project using Foundation for BTB I noticed everything was measured in REMs instead of pixels, which I found a bit odd – especially because it’s difficult when inspecting a page with developer tools to figure out what this seemingly arbitrary number in REMS used as a width actually means.

I’m still unsure on REMS. Although I’ve been using EMs for a long time for font sizes, I didn’t see the point in REMs. And I’m still a bit unsure of the benefits, but Foundation mostly uses them, and in many cases provides a converter function – rem-calc() – to make sure all units are in a consistent metric (definitely useful when you’re doing calculations).


I tried a while ago camel casing my classnames, but it was a short stint that ended up irritating me. Now I like to hyphenate everything, which is fine, because CSS is mostly hyphenated anyway.


I’ve been using Subversion, which is… fine. It’s nice and customisable. Although I miss PHPStorm’s ability to easily format a CSS or HTML document’s tabbing (if it all goes pear-shaped). Subversion has this, and there are several plugins, but many seem to get confused, and don’t format quite as nicely as PHPStorm.

I also miss PHPStorm’s ability to automatically detect you’re using SASS and compile it on the fly. Using Gulp is fine, and I still think I’ll have to use it for projects (especially to compile JS), but it’s so nice when moving between projects not having to run gulp each time, or when setting up a new project not having to npm install, gulp install, bower install etc, which irritates me.