The new Behance features a multitude of new ways to explore and discover creative work. But what about the code that powers everything you see and interact with? What’s making everything look so good and feel so smooth?
A big part of the answer is CSS. There have been a lot of advancements in web development recently, not only in terms of the HTML5 and CSS specs but also in the multitude of tools that have been created to assist in CSS development. We can build cooler websites in less time, and the rapid release schedules of popular browsers like Firefox and Chrome mean that web developers can deliver more awesome faster than ever before.
In a series of posts over the coming weeks, we’ll tell you all about how we’ve leveraged various CSS tools and techniques to do different things, along with tutorials including CSS transitions, flexbox, and icon fonts. But we’ll start with the thing that has had the biggest impact on front-end development here at Behance in recent times: the CSS pre-processor Sass.
Part 1. The Sass Way
By now you have probably heard all the rage about CSS pre-processors. They let you do things that CSS developers have been wishing for for ages: variables, nesting, functions, math and so much more. Sound excellent? That’s because it is!
One of the most important changes we made to the new Network is one you can’t see it all. All of the new CSS on Behance was written using Sass, a pre-processor that adds an incredible level of functionality to our CSS development. We had no problem writing plain CSS before, but all the tools Sass provides helped make our code cleaner, more efficient, more reusable and more maintainable. There is a lot of information about preprocessors out there, so instead of providing a tutorial, I’ll show you a few ways that we are using Sass to make our CSS development better.
Mixins allow you to define styles that can be re-used throughout the stylesheet without having to duplicate code. We use them to great effect for printing gradients or properties that require vendor prefixes. For example, your code for a gradient might look like this:
In Sass, our code looks like this:
Much cleaner! Because our gradient mixin specifies all of the various syntaxes for us, the resulting output is the same as the CSS above, but our Sass file is considerably less cluttered and in turn much easier to read and maintain.
- Variables and Loops
You can use variables to store values for a number of data types in Sass: numbers, strings, colors, booleans and lists. One of the most important ways we use them is for positioning sprites. Take our featured ribbon sprite for example:
Every ribbon for every network appears in a row. Hand-written CSS for this would probably look like:
Continued on for 20-something more ribbons. So instead of copy/pasting a rule multiple times and manually changing the y-position of the sprite, we leverage variables and loops to build out the CSS for us, like so:
In 10 lines of code, we’re able to print out the position of every ribbon in the sprite without even having to think about it. And since our network of sites is always growing, all we have to do when a new ribbon is added to the sprite is add a name to the end of the $networks list. If the ribbons are changed to be 38px wide instead of 36px, we only have to change one value instead of many. It’s as easy as pie.
Nesting is a powerful, dangerous beast. The first time you start nesting things, it’s easy to get carried away. It just feels so right! But you have to remember that it still translates directly into CSS. You know that the more selectors you add, the less efficient your CSS becomes, so you don’t want to nest things any more than you would “nest” them in plain CSS. Additionally, since tools like the Webkit Inspector and Firebug can’t show you Sass line numbers out of the box, the more deeply nested your selectors are, the harder they are to find in the Sass file.
Nesting is beneficial in a lot of ways, especially in that it groups related code, but again, we are very careful not to over-nest. When too many lines of code are nested, it’s easy to lose track of where you are in the sequence, making editing more difficult. Too many nested selectors, and now your CSS selectors are unnecessarily overqualified and inefficient. A quick audit of the resulting CSS file can make any overly-nested selectors clear very quickly.
- Imports and partials
Sass has an @import option that will let you import the contents of any other file into your Sass file. Primarily, we use it for importing a file full of variables across many Sass files.
Partials are also useful for files containing more than just variables. A partial is a Sass file whose name begins with an underscore (e.g. _myfile.scss). This file does not directly compile, meaning it doesn’t get compiled into a corresponding CSS file. We use this to extremely great effect on the new (upcoming) Served sites, which will be a blog post unto itself, but we also use it in a few areas of the network where we have a small, specific set of CSS that is re-used in various unrelated parts of the site.
Take our multiple owners image grid for example: it appears on project pages and collection pages which, aside from the grid, do not share many common styles. Rather than including an additional CSS file on those two pages, we keep the CSS in “_multipleowners.scss” and @import it in the Sass files for the project page and the collection page separately. If the grid were ever added to another page on the site, we would simply add another @import line to another Sass file. This makes for much more modular (and thus, maintainable) code.
- Color operations
Sass also has a number of useful built-in color operations. One of my favorite use cases is for RGBA:
which Sass processes and compiles to:
Not only are the days of pulling RGB values out of Photoshop over, but you can also use those handy variables you already set up to easily convert to their RGBA value. Additionally, we use functions like darken to mathematically darken a color by a certain percentage rather than specifying more color values.
- We love Sass!
Sass has changed the way we write CSS for the better. Overall our code is simpler, cleaner, more modular, and easier to write and maintain. I don’t feel that Sass should be a replacement for knowing the ins and outs of CSS, and it can be certainly be used in a way that produces bad code; but when used as a tool on top of your CSS knowledge to help you be more efficient, Sass is a CSS developer’s dream come true.