CSS and SASS tips for better webapps

You can do a lot of awesome stuff with CSS and SASS, but you can also do some silly stuff. Here are a few tips to avoid some common pitfalls within your webapps.

Try to use classes over IDs where possible

It may sound like a good idea to use IDs if you are going to use an element only once, but what if you want to use that element again somewhere else? Or you want to reuse child elements somewhere else? Further down the line, after many devs have worked on your once shiny code these IDs may become a maintenance nightmare.

Classes keep things portable, and although IDs do offer a slight performance increase over IDs I tend to come from the perspective that maintainable code will perform better over time as it won’t get hacked to pieces. The one place where I do recommend using IDs is for your pages layout and structure, these elements should never be used more that once.

Use SASS variables and functions where possible

I cannot stress enough how sweet SASS variables are! If you use a value, such as a colour or a text style more than once then make it into a variable or function. Developers that work on your code further down the line will thank you for it big time.

Try to limit levels of inheritance where possible

This one is less obvious I think, since inheritance is one of the most useful features of CSS and SASS makes it even more awesome by allowing you to group parents and children together. However the more levels of inheritance you have the less portable your elements are, multiple levels of inheritance also degrade performance (though not to a huge degree).

So if you get to the point where the CSS for an element is nested under 3 or more parents then consider decoupling the element from it’s parents. In the future someone may want to reuse the element elsewhere or change the parent elements, you will make this job much easier if your CSS rules have only 1 or 2 levels of inheritance.

Always combine and minify

This is a well know tip, but it’s worth reiterating. The less http requests made by your app the better, in a big webapp with ads and third party calls you will likely have a ridiculous amount of http requests going on, so it’s best to minimise these where possible. The advantages of minifying are pretty obvious enough, making the http request for your CSS smaller is most definitely going to speed things up.

SASS provides a nice way to achieve both of these, if you follow the structure that I talked about in my article on structuring webapss using SASS then SASS is essentially combing the files for you already, you should be using one SASS file per module/action that combines all the CSS that you need into one file.

SASS also has a minify option, so when it compiles your CSS files it will automatically minify them for you, to do this pass the compression flag to the watch command like so:

sass --watch a.scss:a.css --style compressed

Arrange sprites into grids and declare them obviously

Over time sprites can become super unwieldy and difficult to maintain, with seemingly random image placements and a feeling that if you start moving stuff around you will mess up the look and feel of a lot of elements without knowing it. This can make future maintenance very painful indeed.

You can help combat this by making your sprite usage more obvious to a person that is new to a webapp. First off, giving your sprites a regular arrangement by using a grid in your image editor of choice can really help with not only with making sense of the sprite itself but also with the background position settings in the webapps css. I hate seeing random background positions like ‘-127px -93px’ wouldn’t it be better if your positions were all in multiples of of 20px?

In addition to using grids, have a sprites section at the top of each CSS/SASS file as well and declare all elements and sprite styles here so another dev can easily ascertain what elements are using sprites. Don’t declare the exact position at the top though, just add the sprite as a background-image and declare the actual position where you declare the element later on in the file. Here’s an example:

/*========================================
SPRITES
==========================================*/

.element1,
.element2,
.element3{
    background:url("/images/sprite1.png") no-repeat transparent;
}

.element4,
.element5{
    background:url("/images/sprite2.png") no-repeat transparent;
}
...
.element1{
    background-position:0px 0px;
}

.element2{
    background-position:0px -20px;
}
...

Use SASS partials like you would partials/components/tags/whatever in your webapp

Like your code, this will make your SASS styling more portable. When you write webapps you will no doubt be breaking it down into actions and components (or partials or whatever). I’ve already talked about having a different SASS sheet for each action/view, but why not take it one step further and have a SASS partial to go along with each of your webapps components?

This will not only result in portable and maintainable styling, it will also mean that within your SASS files you will only be pulling in the required styling for each action/view, in the same way that your webapp should only use the components required for each action.