After a long absence of no blog posts on this website, I’m back.

Here is the main reason…

Joel McGlynn

Joel is an adorable excuse! in a non-biased way of course.

So after much thought, I’ve decided that I want to focus on writing more about the web development news and of course, my experimentation and how I go about using new technologies.

I’ll revisit my past posts and comment on how I’ve used these technologies and how they apply to everyday use in real life projects.

At the time of writing, Foundation 6 has been released so I’m keen on experimenting with this framework even though I’m an avid Bootstrap fan.

CSS Architecture

I’m attempting to compile a comprehensive list of how developers and front-end engineers structure their CSS using the SMACSS (Scalable and Modular Architecture for CSS) approach.

What is SMACSS?

SMACSS stands for Scalable and Modular Architecture for CSS, and is more a style guide than a CSS framework. On a high level SMACSS aims at changing the way we are turning designs into code. Instead of working in a page mentality where you try to turn a single page design into code, SMACSS aims to identify repeating visual patterns. Those patterns are then supposed to be coded into flexible/re-usable modules, wich should be independent as possible from the individual page context. This is not a revolutionary point-of-view for a programmer, but in the web design world this is indeed a newer way of thinking.”

“The basic concept of SMACSS is to divide styles into 5 categories: base, layout, modules, states and theme. Each category comes with a set of usage rules and naming conventions. The main reason of this categorization is that rulesets should only ever inherit and add to previous ones, never undo.” – Bram Smulders

According to Ben Frain, (Enduring CSS: writing style sheets for rapidly changing, long-lived projects) “it’s a common pattern to split up files in a project by technology type”.

- html/
- js/
- sass/
- css/

He continues to say, “I therefore favour a situation whereby rather than organise by technology type, files are organised and grouped by visual component. So, instead of this:”

- shopping-cart-template.html
- callouts-template.html
- products-template.html

- shopping-cart-template.js
- callouts-template.js
- products-template.js

- shopping-cart-template.css
- callouts-template.css
- products-template.css

“We aim for something like this:”

- shopping-cart.html
- shopping-cart.css
- shopping-cart.js

- callouts.html
- callouts.js
- callouts.css

- products.html
- products.js
- products.css

According to Bram Smulders, (How I improved my workflow with SMACSS & Sass) “in Sass you can easily chop your stylesheet into partials by using the @import rule. This allows us to easily organize and maintain our files similar like this:”

- theme.scss

	- theme/_base.scss
		- theme/base/_reset.scss
		- theme/base/_headings.scss

	- theme/_layout.scss
		- theme/layout/_masthead.scss
		- theme/layout/_main.scss
		- theme/layout/_footer.scss

	- theme/_modules.scss
		- theme/modules/_search.scss
		- theme/modules/_gallery.scss

	- theme/_state.scss
		- theme/state/_mediaqueries.scss

Jonathan Path and Laurent Sutterlity, created Sass + SMACSS which combines Sass with SMACCS.

And here’s an example of the folder structure:

On a very similar approach is Mina Markham’s Sassy starter – HTML / SCSS (SMACSS) and this is an example of the project’s file structure.

+ scss/
 | + base/         # reset, typography, site-wide
 |  |-- _index.scss    # imports for all base styles
 |  |-- _base.scss    # base styles
 |  |-- _normalize.scss  # normalize v3.0.1
 | + layout/        # major components, e.g., header, footer etc.
 |  |-- _index.scss    # imports for all layout styles
 | + modules/       # minor components, e.g., buttons, widgets etc.
 |  |-- _index.scss    # imports for all modules
 | + states/        # js-based classes, alternative states e.g., success or error state
 |  |-- _index.scss    # imports for all state styles
 |  |-- _states.scss   # state rules
 |  |-- _print.scss    # print styles
 |  |-- _touch.scss    # touch styles
 | + themes/        # (optional) separate theme files
 |  |-- beccapurple.scss # rename to appropriate theme name
 | + utilities/      # non-CSS outputs (i.e. mixins, variables) & non-modules
 |  |-- _index.scss    # imports for all mixins + global project variables
 |  |-- _fonts.scss    # @font-face mixins
 |  |-- _functions.scss  # ems to rems conversion, etc.
 |  |-- _global.scss   # global variables
 |  |-- _helpers.scss   # placeholder helper classes
 |  |-- _mixins.scss   # media queries, CSS3, etc.
 |  |-- _lib.scss     # imports for third party styles
 |  |-- + lib/      # third party styles
 |    | _pesticide.scss # CSS pesticide
 |    | ...
 |  + ie.scss       # IE specific Sass file
 |  + styles.scss     # primary Sass file
 |  + _shame.scss     # because hacks happen
 + .htaccess        # Apache server configs
 + config.rb        # Compass configuration file
 + crossdomain.xml     # cross-domain requests
 + docs/          # SassDoc generated documentation
 + deploy.rb        # Capistrano configuration file
 + Gruntfile.js      # Grunt configuration & tasks
 + package.json      # Grunt metadata & dependencies

According to Hugo Giraudel, (Architecture for a Sass Project), he likes to structure his Sass files as:

|– base/ 
|   |– _reset.scss       # Reset/normalize 
|   |– _typography.scss  # Typography rules 
|   ...                  # Etc… 
|– components/ 
|   |– _buttons.scss     # Buttons 
|   |– _carousel.scss    # Carousel 
|   |– _cover.scss       # Cover 
|   |– _dropdown.scss    # Dropdown 
|   |– _navigation.scss  # Navigation 
|   ...                  # Etc… 
|– helpers/ 
|   |– _variables.scss   # Sass Variables 
|   |– _functions.scss   # Sass Functions 
|   |– _mixins.scss      # Sass Mixins 
|   |– _helpers.scss     # Class & placeholders helpers 
|   ...                  # Etc… 
|– layout/ 
|   |– _grid.scss        # Grid system 
|   |– _header.scss      # Header 
|   |– _footer.scss      # Footer 
|   |– _sidebar.scss     # Sidebar 
|   |– _forms.scss       # Forms 
|   ...                  # Etc… 
|– pages/ 
|   |– _home.scss        # Home specific styles 
|   |– _contact.scss     # Contact specific styles 
|   ...                  # Etc… 
|– themes/ 
|   |– _theme.scss       # Default theme 
|   |– _admin.scss       # Admin theme 
|   ...                  # Etc… 
|– vendors/ 
|   |– _bootstrap.scss   # Bootstrap 
|   |– _jquery-ui.scss   # jQuery UI 
|   ...                  # Etc… 
`– main.scss             # primary Sass file

According to Cathy Dutton, (8 Tips to Help You Get the Best out of Sass) “getting your site structure correct from the beginning is vital for any new Sass project. Using partials allows you to break the CSS up into smaller more manageable blocks of code that are easier to maintain and develop.”

“Partial files are created using an underscore and are not output as separate CSS files. Each partial should be imported using a master Sass file (global.scss) in the root of the Sass folder.”

|-- _variables.scss
|-- _mixins.scss
|-- _placeholders.scss

According to John W. Long, (How to structure a Sass project) “one of the most useful features of Sass is being able to separate your stylesheets into separate files. You can then use the @import directive to include the source of your individual files into one master stylesheet.”

“But how should you structure your Sass projects? Is there a standard way of separating out your CSS files?”

“I like to layout my Sass projects like this:”

|-- modules/              # Common modules
|   |-- _all.scss         # Include to get all modules
|   |-- _utility.scss     # Module name
|   |-- _colors.scss      # Etc...
|   ...
|-- partials/             # Partials
|   |-- _base.sass        # imports for all mixins + global project variables
|   |-- _buttons.scss     # buttons
|   |-- _figures.scss     # figures
|   |-- _grids.scss       # grids
|   |-- _typography.scss  # typography
|   |-- _reset.scss       # reset
|   ...
|-- vendor/               # CSS or Sass from other projects
|   |-- _colorpicker.scss
|   |-- _jquery.ui.core.scss
|   ...
`-- main.scss            # primary Sass file

“This allows me to keep my primary Sass file extremely clean:”

// Modules and Variables
@import "partials/base";

// Partials
@import "partials/reset";
@import "partials/typography";
@import "partials/buttons";
@import "partials/figures";
@import "partials/grids";
// ...

// Third-party
@import "vendor/colorpicker";
@import "vendor/jquery.ui.core";

How do you structure your CSS/Sass files?

Based on the findings, it looks like incorporating Sass/Scss files into your folder set up is the best way to start your project. Of course, assuming that you’re using Sass (and if you haven’t starting using Sass, why not?!)

There are plenty of resources to get your projects set up the right way but of course, everyone has different ways of approaching a file structure. So no matter how small or large your site will be, I hope these examples can help you look at CSS architecture differently for your next project.


Further Reading

Using Bourbon, Neat, Bitters & Refills

So why am I contemplating using Thoughtbot products when Bootstrap is so popular and much widely used in the web community?

  • Bourbon – “A simple and lightweight mixin library for Sass.”
  • Neat – “A lightweight semantic grid framework for Sass and Bourbon.”
  • Bitters – “Scaffold styles, variables and structure for Bourbon projects.”
  • Refills – “…prepackaged patterns and components, built on top of Bourbon, Bitters, and Neat.”

The idea of using clean and semantic markup that is based entirely on Sass mixins was pretty much the key factor which attracted me to try out Bourbon, Neat, Bitters and Refills.

But don’t get me wrong, I’m not about to bash Bootstrap as I enjoy using it to flesh out projects that require quick turn-around times and I’ve also written a previous post on how to use semantic classes in Bootstrap.

As one of the co-creator’s of Neat, Reda Lemeden writes in his post Introducing Bourbon Neat, a Sass-based responsive grid framework, he states that:

We built Neat with the aim of promoting clean and semantic markup; it relies entirely on Sass mixins and does not pollute the HTML with presentation classes and extra wrapping divs. It is less explicit—as in requires fewer mixins—than most other Sass-based frameworks and comes with built-in table-cell layout support.

The main motivation behind Neat is allowing anyone to build fluid, entirely semantic grid layouts without having to wade through hundreds of lines of documentation. We also believe that giving designers the ability to override the default behavior without hassle is key.

For the simple fact that it’s lightweight in size and is based on Sass mixins was enough for me to experiment with this framework. It also means none of the bloated and unused code of the framework will weigh down the loading time of your site as only the mixins you’re using gets compiled (to get your final CSS output). This is definitely a huge plus.

However there are caveats of using Bourbon and Neat that should be kept in mind. In this post Create responsive grid layouts with Bourbon Neat, by Derek Blank, he states that “IE7+ support is possible when Bourbon is used with Selectivizr for CSS3 selectors and Respond.js for media queries.”

Experiences with Bourbon, Neat, Bitters and Refills

After watching the series on Awesome CSS with Bourbon, Neat, Bitters & Refills! by PHP Academy, I installed Bourbon, Neat and Bitters.

When I wanted to use refills (and after compiling), the following error message appeared:

"Error: $large-screen (refills) variable not defined"

In Part 6 of the series, I noticed that other people had similar issues to me when following this video tutorial.

So to overcome this error, I did the following:

  1. Doing a Google search I found a post on PHP Academy (which no longer works)

    Instead of uncommenting line #4 in bitters.scss, it’s now uncomment line #8 in the base.scss file.

  2. Then within the base folder, find grid-settings.scss and comment out:

    @import 'neat-helpers';

    and use:


    I’m making the assumption that you’re developing in a non-rails environment.

  3. And finally, the order of your @imports in your styles.scss need to be listed in this order:


    Another assumption is that you’re using Neat.

Newbie Error

I wanted to include Normalize to my project but I made the mistake of naming: @import “normalize.css” in my main styles.scss file.

Instead I should re-name “normalize.css” to “_normalize.scss” as a partial file and therefore within my styles.scss file, the name of the normalize import should be:

@import "normalize"; 

The benefit of this is to reduce the number of http requests if you are linking directly to the normalize CSS file.


Start using Sass

I really wanted to point out the reasons why web developers should start using Sass and I came across the Clean out your Sass junk drawer slides by Dale Sande. It shows just how much the thought process of well structured CSS has changed over the years. So if you still work with fellow front-end web developer/engineers who aren’t using any CSS Preprocessor, point them to these slides.

CSS3 Background-Image

While creating a prototype for a project (using Bootstrap), I added the Jumbotron component which is described as: “a lightweight, flexible component that can optionally extend the entire viewport to showcase key content on your site” and found that my background image wasn’t responsive at all.

After searching on Stack Overflow, I found that using “background-size: cover” to the Jumbotron class works to make the background image responsive. For example, see below:

    background: #efefef url(image.png) no-repeat center center fixed;
        -webkit-background-size: cover;
	-moz-background-size: cover;
	-o-background-size: cover;
	background-size: cover;

So here’s a more in depth look at using “Responsive Full Background Image Using CSS” by Jacob Gube.

“The CSS background-size property can have the value of cover. The cover value tells the browser to automatically and proportionally scale the background image’s width and height so that they are always equal to, or greater than, the viewport’s width/height.” – Jacob Gube

Jacob continues to say that “to enhance the page load speed on small screens, we’ll use a media query to serve a scaled-down version of the background image file.” He further states the reason to use media queries is that “it’s a huge payload just for a background photo” which is never a good thing and that “it’s exceptionally bad on mobile internet connections”. Adding that “the image dimension is excessive on small-screen devices”.

Jacob wraps up his tutorial by stating, “if I can say just one cautionary thing about this technique, it’s this: Please use it with care because large files can severely affect UX, especially when our user is not on a fast or reliable Internet connection. This is also the reason why you should set a good default background color so the user can read the content while the background image is loading.”

So this is all well and good for the majority of browsers, except for IE8. If you look at Can I Use you will see that IE8 doesn’t support this CSS3 feature.

To overcome this issue, I found an article on “How to Enable Background Size in Internet Explorer” by Thoriq Firdaus.

Thoriq demonstrates how the CSS3 Background Size property can be used in Internet Explorer. He states that “unfortunately, this feature does not fallback nicely in Internet Explorer 8 and below. If you attach a very large image, it may overflow the container.”

So Thoriq mentions to use the Background Size Polyfill developed by Louis-Rémi. This polyfill “replicates the same behaviour of background-size property with cover and contain values. This polyfill comes in the form of an HTC file named backgroundsize.htc, and an .htaccess file, which is required when the page is served from Apache server to send the .htc mime-type.”

He goes on to provide the following instructions, “to use it, include the HTC file through the Internet Explorer behavior property, as follows.”

.background-size {  
        width: 500px;  
        height: 320px;  
        background-image: url('img/image.jpg');  
        background-size: cover;  
        -ms-behavior: url('http://example.com/js/backgroundsize.htc');  

I’ve noticed in the code example above, that it’s probably not a good idea to give your class and CSS selector the same name eg. background-size.

He goes on further to instruct “…if you are using Apache server, place the .htaccess in the root folder of server or, simply add this line to the existing .htacces file, if available.”

AddType text/x-component .htc