Combining media queries in Foundation

I really like the way Foundation makes media queries easy by putting them into variables, so that I can easily put breakpoint into a CSS class. Like this:

.my-class {
   font-size: 1rem;

   @media #{$large-up} {
      font-size: 2rem;

I’ve written before about the way I write media queries (see here), and I think this is the best way to avoid hunting through documents to find a selector that might be in a separate breakpoint somewhere.

However I sometimes want to combine multiple breakpoints to save duplication. For a long time I thought this wasn’t possible, but you actually can by writing it like this:

@media #{$small-only}, #{$large-up} {


I find this useful with height breakpoints

Sometimes I need to use a media query that detects the height, to make sure we’re not using elements that are too large.

I’ve made my own height media queries as variables:

$short-only: "(max-height:600px)" !default;
$tall-up: "(min-height:601px)" !default;

I use “short” and “tall” for height like you’d use “medium” & “large” for width (maybe Foundation should change their variable names to “narrow” and “wide” instead?).

I admire this guy for not using a preprocessor, but I just couldn’t

I read this article today about someone who doesn’t like using preprocessors (like LESS or SASS) to compile CSS. It’s worth a read, here it is:

I put off learning SASS for a long time, because I find it fiddly. You have to install something, and often have to run commands in a command prompt (something I hate), running gulp or grunt or whatever. But I was converted when I realised PHPStorm did it for you – which is AWESOME.

But now that I do, I feel like I can write styles so much clearer and more effectively, without getting lost in a massive page of WET CSS code. I use the word WET as the opposite of DRY (don’t repeat yourself), as without compilation your CSS can end up with lots of repetition. Especially if you need to target things inside a specific class, you might end up with this:

.main-content p,
.main-content ul {}
.main-content h1 {}
.main-content h2 {}

Look how many times you have to type .main-content! Whereas in SASS you could write:

.main-content {
   p,ul {}
   h1 {}
   h2 {}

Isn’t that cleaner?

There’s also loads of advantages – being able to split code into useful components you can paste between projects, rather than one big mass of CSS. Also, keeping colours as variables is amazing. I’ve no idea how I managed before that!

Here’s more articles about the way I like to write styles:

Here’s an article to read about preprocessors: Why your reasons for no-longer using a CSS pre-processor are wrong, and you’re wrong, and you should feel bad.

Overriding a pesky parent selector with ninja specificity

ninjaI try and keep my CSS/SCSS in a fairly flat structure, and recently on a project I’ve been bugged by a parent selector which has been adding quite specific styles that have been getting in the way of my own.

The class is called .copy and has colour styles for <p>, <h2> and for <a>. So if I try to do something specific like give a result title a different colour, it gets overridden by the .copy h2 style.

I could of course make all my styles more specific, but this means adding in another class wrap all my SASS in body or an arbitary class further up the structure, but that’d annoy me because it’d be inserted into the css loads of times unnecessarily.

So I’ve taken to adding in extra selectors to provide more specificity, like this:

.result {
      &__title a,
      .copy & &__title a {


Using the ampersand at the end of the line which in SASS will insert the parent (my new favourite thing) means that I’m covered for if the .copy class overrides my style, but without putting this style somewhere weird that I can’t find later.

It means I’ve added a bit of extra specificity which leaps in like a ninja when I need it, and I don’t have to do it to the entire section.

I’ve discovered the ampersand selector in SASS & now I’m using it everywhere!

Once I discovered you could use an ampersand selector in SASS to reference the parent, I haven’t gone back. I’m using it everywhere because it’s so useful. Here’s an example copied from an article – the article explains it better than I ever could.

  font-size: 20px
  margin-bottom: 10px
  .some-parent-selector &
    font-size: 24px
    margin-bottom: 20px

And here’s how the output CSS looks.

h3 {
  font-size: 20px;
  margin-bottom: 10px;
.some-parent-selector h3 {
  font-size: 24px;
  margin-bottom: 20px;

This is very useful! Especially when you want to keep css together by usage (I wrote about that here) so that you aren’t looking in multiple SASS files for information about every modification of a style.

Here’s how I used it today – I’ve got a class called “.copy” which is used for the content section of a page. There’s useful things in there like how the links and list items should look, because they’re a bit different to in the chrome (header & footer). But I wanted to create an aside section with different coloured text. Problem was, .aside p is the same specificity as .copy p, and I don’t want to start adding !important which could cause problems later on.

So I wanted to increase the specificity, but I didn’t want to add these styles for the aside inside the copy.scss – because that’s detached from the rest of the styles (which are in aside.scss). So I did this in my aside.scss:

.aside {
   .copy & p {
      color: #484848;

Notice it’s between the .copy and the p. It outputs like this:

.copy .vacancy-aside p {
   color: #484848;

Neat ways to write BEM without being verbose


I love naming classes using BEM, which is a good way to indicate what classes represent (and where to find them in your project), without forcing it into a hierarchy that will cause problems later if you have to change the markup.

Problem is, it can get a bit verbose though.  Especially if you’re being super specific with your names. Writing CSS selectors for long class names is repetitive and annoying. So here’s 2 tips for making it easier using SCSS: Continue reading Neat ways to write BEM without being verbose

Keeping CSS classes together by usage

I’ve written before about keeping your CSS grouped by component, so that styles for a specific part are not distributed wildly around the project and difficult to find.

This is normally done because of media queries. A common thing people might do is to split the stylesheet into 3 chunks. Styles for mobile, styles for tablet, and styles for desktop (or more, depending on how many breakpoints you decide to have). But I prefer to put all styles for a specific component in one place, to save you chasing these around. Even if it does mean having loads of media query declarations. But that doesn’t matter! (I use variables for these anyway). Continue reading Keeping CSS classes together by usage

My opinions on using or not using Bootstrap

I found an article today titled “Strapless” by Aaron Gustafson (read it here) with some arguments for not using Bootstrap in your project. I use Bootstrap all the time, and I feel it saves a lot of time when starting a new project. Here’s my opinions on his points:

1. Bootstrap doesn’t solve your problems. Design is problem solving. The design decisions made by the creators/maintainers of Bootstrap solve their problems, not yours. You may share some of those problems—a need for responsive layouts, for example—but not others. You need a system that is tailored to solve your problems and only you (and your team) know what those problems are. Have you ever tried on an article of clothing that’s “one size fits all”? How well did it fit your body type? Unless you are absolutely average in all respects, probably not all that well. Solve your problems with your own Bootstrap-esque pattern library.

I actually agree with this point, but Bootstrap is a starting point, not a full solution. I like it because I can get something working really quickly, and can make the structure of a page, then refine it and change the look and feel later.

2. Bootstrap offers more than you’ll need. Bootstrap contains a lot of components and design patterns. It was created to address a wide array of project needs

Okay yeah, it is a bit bloated. It’s crammed full of stuff that you might never need – but actually that’s something I really like about it! If you suddenly need to add a carousel, there’s one built in. If you suddenly need to add a responsive wrapper for a Youtube video, it’s there. If you suddenly need to add a modal, it’s there. Same for lots of other really standard stuff.

Plus as long as you’re using the Bootstrap SCSS files and not the final exported version, you can pick and choose which sections you want, and comment-out the ones you don’t need. Here’s the _bootstrap.scss file for one of my projects where I’ve just uncommented the components that aren’t needed. These won’t be compiled into the final css, so there’s no bloat. But I can add them back in really easy if I need them. bootstrap file in phpstorm

If this isn’t how you include Bootstrap, you should (IMO anyway), and here’s an example project to get your started.

3. Differentiating yourself from you competition is harder. Bootstrap sites have a very common look to them.

Yeah but a Bootstrap site doesn’t have to look like a Bootstrap site! It’s a starting point, a framework. Sure if you keep the default theme, it will look like a Bootstrap site, but you can expand on that and add your own styles.

The major benefit I find is that it makes your markup standard, which means anyone who’s familiar with the Bootstrap classnames will save time when switching between projects and having to figure out how it all works!

Check out the rest of Aaron’s arguments here.