Christian Naths, 780-231-4131, @christiannaths

Finally, a Sass project folder structure I actually like.

Nov 3, 2014

I've been working with Sass for quite some time; since about 2009 when it started to make a name for itself in the Rails community. It helps me write stylesheets more modularly, since its @import adds the code on pre-compile, rather than adding additional HTTP requests in the browser.

However, with the ability to break your code up into many separate files comes incresed complexity in your project structure: how do you keep it all organized? It's a problem that seems simple on the surface, but it's one I've struggled with pretty much since the beginning.

I think I've finally come to a nice, easy solution. In the current landscape of BEM, OOCSS, Atomic CSS, and SMACSS, it all can get a bit overwhelming. Having looked at all of these, I find OOCSS most attractive at it's core principles. The Github project itself is a huge turnoff in terms of complexity though, so I never really gave it a fair shake. It also doesn't seem to lend much in the way of file/folder structure.

Anyway, here's what I've landed on, in a project I'm currently working on. For the first time in quite a while, I'm pretty happy with how this is turning out.

figure 1
My assets/stylesheets directory


Things start off with a config directory. This is where I set up my document. Far-reaching changes occur here, like setting the document to use box-sizing: border-box and things of that nature. I also use this folder to store changes to elements on a micro-level. This is akin to an "atom" in Atomic CSS, but I've been using the term "base", since the rest of my CSS will inherit from it.

This directory also inevitably holds some setup files, such as a helpers file for my mixins, or a theme file which initializes some colour variables.


Here is where I create files for basic CSS elements. This is akin to a "block" in BEM. However, some elements may be just a single HTML tag: buttons are a good example of this, but I allow them to get more complex as well.


Layouts are styles for sets of structure only elements. They can have far-reaching consequences, so special HTML is usually written to accomodate for this. I'll generally have a "base" set of styles which the specific layouts inherit from. If the project is very simple, this folder can be substituted for a single "layout" file.


Views are location-based styles. Body classes are applied to facilitate styling elements differently in a particular view. For example, the "locations" page might need a full-width map, but the "events" page might only need a thumbnail. Both will use the same element with the same class name, but I can adjust the styles per-page using a view stylesheet.

That's pretty much the gist of it. Nothing too ground-breaking here, but hey, sometimes the simplest solutions work best :)


Some thoughts on mixing css floats

Nov 1, 2014

A collegue asked me a question about mixing the use of float:left and float:right yesterday, which I thought was interesting. He asked:

I've been living by the rule of "don't float in two directions" for years now, but I forget why, and I can't find justification on the internet. Why not float in both directions?

First off, you’re right. There is very little info about this online. The simplest answer I can give for this is: it ends up being problematic in the long run. If you are not confident you know what the width of your container (fixed/fluid width wrapper element) will be, it is just messy to work with, and when your floats “break”, it is difficult to understand why. Also, if you container is ends up wider than you think you will end up with gaps between your elements, which is usually not desired (even if it is desired, there’s a better way to accomplish that).

In a broader sense, the problem with this for me is the overall way of thinking. I prefer to think of my CSS structure as a tightly knit set of elements that simply holds content for me. I tell students to think of their grid as if the page were laying on it’s side, and the elements had weight. Floating left to every grid-type element reinforces that line of thinking. The internal dialog goes something like “float it left, float it left – oops no more room, next line…”, and so on. If suddenly you throw something in there that’s floated to the right it’s like that element is living in a different universe, with a different set of physics governing its behaviour. Like gravity suddenly works in reverse. It’s chaotic and difficult to manage.

I can’t count how many times I’ve helped one of my students with a broken float, only to find they have an element floated right amongst their left floated elements. All I’ve ever had to do in those cases is suggest they float everything left, and check their element widths. Nearly every time they’ve been able to solve their issue with only that advice.