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.

4 examples of CSS being weird

I know many people find CSS quite difficult, and often I see this gif shared as an example of how people work with CSS:

Peter Griffin doing css

But if you’re doing CSS like this, YOU’RE DOING IT WRONG! CSS isn’t that difficult, but sometimes the chosen syntax does make me WTF. Here’s some examples of that:

Comma inconsistencies

Sometimes you need a comma to differentiate multiple values, like:

transition: color 200ms, background 200s;

But sometimes not:

transform: translateX(-50%) translateY(-50%);

Why isn’t this consistent?!

Slashes in shorthand

Ever seen this?

font: 12px/18px "Lucida Grande", sans-serif;

The first 2 values are shorthand for font-size and line-height. Why they’re separated with a slash though seems unusual as I’ve not seen that used anywhere else.

Apart from you can apparently use it in border-radius (here’s an article explaining that) to separate horizontal and vertical axis, but again – that’s inconsistent to how we do it elsewhere!

Camel Case or hyphen?

CSS has always been hyphenated, for example background-color, text-transform etc, so why did we start adding camelcase like translateY, rotateX? It’s inconsistent!

Edit – Also, overflow-y and translateY – Y so different?

Vertical Percentages are Relative to Container Width, Not Height

I didn’t actually realise this for a long time. It can be really useful once you know what it’s doing. Here’s an article about it. But why can’t I also set a height based on a percentage of the container’s height?

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

Don’t scrimp on classes if it means making convoluted CSS

I’ve been reading Harry Robert’s chapter in the “New perspectives on Web Design” book today (he even signed it for me, which was hilarious because apparently nobody had ever asked him that before!), and there’s a great bit talking about reducing the amount of DIVs to create clean markup, and how it’s just cutting off your nose to spite your face.

The pursuit of clean markup and semantic classes and all that came with it was well-intentioned but helped no one. It led to verbose, difficult to maintain, tangled style sheets. The price of omitting a few classes was having to write giant, convoluted selectors to target these orphaned, unnamed DOM elements. As the saying goes, we robbed Peter to pay Paul. We were writing clean markup at the cost of writing verbose, messy and convoluted CSS. We just moved the mess somewhere else.

  • Harry Roberts, New perspectives on Web Design

Avoiding location-based inheritance in CSS

I had a thought today on a personal HTML/CSS project about how to style a light button in a dark container, and how to style a dark button in a light container.

Should I use CSS inheritance to make the button the appropriate colour in each area? That makes sense right? It means I can write HTML not really caring about the styles, and let the CSS do the rest.

But then I worried about what happens if I use the button elsewhere, out of the container. If the coloured container provides the styles, I’ll need at least some base styles on the button. And which one should be the default? Light on dark, or dark on light?

Let’s say light container is the default, so the button by default is dark.

What about then when we want the button on a different coloured background, maybe a red container inside the dark container. We’d have to override the button’s default styles to make it dark on light, then override these again to show as [I dunno, yellow?] on the red background.

I know the “C” in CSS stands for cascade, but this can get out of hand!

There’s a good article about this I found today, which has this great line that I need to repeat over and over.

…your styles will be more flexible and less prone to breaking if you avoid relying on location inheritance.

Read the rest of the article here. It takes you through a good use case of how inheritance can cause problems. It also talks about how “multiple inheritance” can also get out of hand, and solves it with SASS extends, although I prefer more of a BEM approach, but the idea of being very specific about your styles is the same.