blog logo
[ultimatesocial count="true" networks="linkedin,facebook,twitter" url="" skin="minimal"]

Putting the Fun Back into CSS

Steve Susina • May 24, 2013

Look over the code output from a CMS like Drupal, and you might be astonished to see just how extensively it manages front-end content markup. There are divs,  classes and ids for everything. And if there isn’t a class in place, an administrator can probably create one in the system’s configuration.


Drupal is not alone in this attention to detail – most top-notch CMS systems and store fronts offer an array of possibilities for front-end markup. When more than one system is involved on the same site (as sometimes happens here at lyonscg, when Magento and Drupal are built to share different site tasks) the markup can be robust, to say the least.


While this feature offers deep control over a site’s look and feel, the structure itself can lead to code bloat for CSS files as different team members with different coding styles manage separate areas of a project. With even a few team members contributing to a project, it’s not unusual for even the simplest CSS file to mushroom into a behemoth. Worse yet, editing the files for cross-browser compliance requires a Frankenstein array of tools and testing techniques, leading to a tedious and costly bottleneck in the production chain.


But SASS – a scripting language for writing CSS3, and Compass – a ruby-based “CSS framework” that extends and compiles SASS files, promises to significantly simplify front end development.  This combination reduces code bloat, generates bulletproof cross-browser compatible CSS3 files, and makes editing faster and easier.  It can be integrated with any framework while requiring no additional server resources. And best of all, it’s really easy to use. For team CSS development, all of these point to a winner.


If you’re not familiar with SASS (Syntactically Awesome Style Sheets), it’s important to understand that the language is basically CSS shorthand whose files are compiled –generally in the background – during development.  It’s really more of a developer’s tool than a web site addition. This is why SASS doesn’t take up additional server resources at run time – you’re still serving up the same static CSS files you always do. Only now, you’re working smarter.


There are two ways to write SASS files, and these methods are essentially dialects of the same language – the older .sass format,  which uses line breaks and indentation to create sparse styling documents, and .scss, which looks more like traditional CSS markup.


SCSS is somewhat easier to understand since it uses the same bracketed coding style as traditional CSS. In fact, it’s so similar to regular CSS that the perpetually lazy don’t have to change a thing: There’s no penalty for writing .scss files with the same old CSS syntax. However, you’d be crazy not to take advantage of some of the enormous benefits SASS provides.


For example, SASS lets you give human-readable names to CSS attributes. In fact, name anything, since SASS uses variables. When I first started learning CSS, the idea that a language as important as CSS didn’t include variables was inconceivable to me. After all, if the WC3 can arbitrarily name colors, why can’t individual developers?  Well now you can, since SASS offers is the inclusion of variables that look a lot like plain old PHP.


Now, rather than writing:


background-color = #789789 (and having to remember or  look up that particular hex color every time you need to reference it)


you just define a SASS variable as you would any standard PHP code:

$brick-red = #789789;




background-color: $brick-red;


From here on out in your style sheets, you’ll write $brick-red whenever you need to invoke that color, and skip looking up the hex-code. This feature alone offers developers a massive time savings, since you can define all your color values as variables and change them globally in one line of code.


However, variables are useful for a lot more than naming colors. They can also be used for math, a feature that’s especially useful when building responsive designs.


For example, let’s say your creative department spec’d an odd-sized grid that departs from the standard 960px width. If you already use a custom theme you’d be faced with the chore of manually recalculating column widths for each view port. But why bother? Rather than having to re-write anything at all, you can build your responsive styles with SASS variables and let it do to the math. For instance:  


            $container_width = 800px;

            $main_column_width = 400px;

            .sub_column { width: $container_width – $main_colunm_width; }


This is a monumental time saver that is not only faster, it’s also more accurate.


SASS helps untangle the mess: During development, CSS files grow faster than any other type of code, largely because the language is so easy to write, and in the short term, there’s little penalty for writing more –rather than better – code. Since most CMS’s provide some level of CSS compression, unless someone on the team is dedicated to clean code, big, sloppy CSS files are the rule rather than the exception.


Of course this leads to annoyance for people editing the code later. There’s nothing more tedious than debugging a site when its styles are scattered throughout thousands of lines of code in one massive, bloated style sheet.


This is where SASS really helps, providing three techniques that greatly simplify code, including nested markup, includes and mixins.


Nested markup is one the great SASS features you’d think would already exist in CSS. With it, you can group css elements together in a way that approaches the holy grail of front-end development – Object-Oriented CSS. (Insert here the requisite disclaimer that yes, I know, CSS isn’t an Object-Oriented language.)


But OO-CSS is one of those catch phrases that continues to be heard at development conferences because it has so much merit. Consider how most developers approach CSS. Traditionally, styles are sorted by element (links in one section, layout in another, etc.). This structure is fine for small projects, but disintegrates quickly as the site gets larger.  What ends up happening is that after a few hundred lines of code, it’s faster to tack on new additions to the end of the style sheet rather than hunting and pecking for existing declarations.


But nested markup changes that pattern, enabling styles to be grouped by purpose rather than by structure, imposing an order on code that’s efficient and streamlined.  That’s exactly what’s happening in the following code, where we’re defining the behavior of any element with the “callout” div in only a few lines of code:




            color: $blue;

            line-height: 120%;

            background-color: $lightblue;

@include border-radius(10px;)


            color: $red;





                        text-decartion: underline;






While this is a limited example, you can probably appreciate how much easier this code is to edit than one created using a traditional structure. Any element, whether it’s a link or a header tag can be nested within the div. This means you no longer have to jump to the beginning of the style sheet to edit an attribute. It’s all right in one place, succinct and easy to follow. 


Psuedo-objects like these can be further compartmentalized from the main style sheets making them really easy to edit down for everyone on the team. This is accomplished through the use of includes.


Imagine you want isolate the main navigation in its own easy-to-follow style sheet. Just create a new document called…say…”navigation” and prepend an underscore to it (“_navigation”). Now you can use SASS’s import syntax by writing @import “navigation”; anywhere within your main .scss file. The underscore we’re adding to the file tells SASS to add this to the main CSS file anytime the file is compiled. This is similar to using CSS’s native @import url(); declaration, but now rather than making another HTTP request, SASS will compile the include into one main style sheet.


In the previous code example, it’s worth calling special attention to the use of a mixin used to generate a border radius in the div.


Mixins are pre- or self-defined snippets of CSS that define a behavior for the given markup. In this case, the mixin tells SASS to write the border-radius so that it’s renderable by every browser. You’ll never need to worry again about the proper radius syntax for Opera, for example, because it will be created automatically for you when SASS is compiled. In this case, the single line @import border-radius(3px) will be magically transformed into separate radius declarations for every browser.


You can write your own mixins if you’d like, referencing them with the same syntax used in the above example. However, an open-source ruby project called Compass offers a full library of mixins, along with a SASS compiler that rewrites SASS into CSS any time a change to one of the .scss files is detected.


Navigate SASS with Compass


Compass is powerful enough to call itself a CSS framework, but after installation in your local development environment, you’ll hardly know it’s there. Just like the .scss syntax, you don’t actually have to change anything about your coding style, although, again, you’d be crazy not to.


Compass installation is done with a simple ruby gem. On a mac, simply open the terminal and type sudo gem update –system, then just type sudo gem install compass. That’s that. (Easy, right?)


What makes Compass so useful is that with a few simple commands, it will set up everything you need to manage styles with SASS, and enable a full library of mixins that are capable of handling almost every CSS3 task you’d ever need. This includes the ability to generate a single master sprite file from any images you’ve used in you css.)  It will also handle all compiling tasks in the background while you work. (Anytime you update a .scss file within your project, Compass will detect it, then recompile the css in the background.)


To get started, just just cd to your project and type “compass create <project name>”


What you’ll end up with is a ruby file with various configuration options, and a few new directories for images, javascript and scss files.


Finally, any time you want to use the Compass/Sass compiler, just cd to your compass directory and type “compass watch”. Until you quit, compass will keep an eye out for changes to your .scss files and recompile them into beautifully formatted code.



Further Reading:

To read up on SASS, visit
To check out compass, visit
To find out more about lyonscg’s ecommerce web development services.




Steve Susina

About the author

Steve Susina

Subscribe to our blog

Let's discuss the next step in your commerce journey.

XSchedule a meeting