This was taken from http://www.netwhisperer.com/2014/01/17/5-ways-css-preprocessors-improve-stylesheets/
5 Ways CSS Preprocessors Improve Stylesheets
Speed up your development time and make your stylesheets easier to maintain.
CSS preprocessors have become essential to my front-end workflow. For non-devs out there, preprocessors allow developers to write code in the preprocessed language, which is then converted into the same old CSS we’ve been writing for years.
Although there’s an up-front cost to setting up the preprocessor environment, the language learning curve is gentle (looks a lot like CSS) and the benefits are vast. With the exception of very small or short-lived projects, writing straight CSS is just doing it wrong. By itself, CSS is a primitive declarative language for setting style switches in the browser and tends to end up an unwieldy mess.
But when combined with a preprocessing framework such as SCSS or LESS,developers can add the conventions of a more powerful programming language to make code easier to read, easier to maintain and faster to develop. All this results in a higher-quality end product.
Following are five techniques I use to leverage the power of SCSS and make my stylesheets better:
1. Use SCSS’s @import option to organize your codebase into separate files
There are drawbacks to dividing styles into multiple files in CSS. For one, each stylesheets included in your page (even when using CSS’s @import option) requires an additional http request and impacts load time. SASS builds on the @import option, combining the files during a concatenation process, so you ultimately serve a single file to the browser.
I typically create a main file that includes a set of @import statements at the top. The types of files I might include are:
|
1
2
3
4
5
6
7
8
9
10
11
|
@include "vendor/bootstrap.CSS";
@include "bootstrap_overrides";
@include "my_variables";
@include "my_mixins";
@include "ui_elements";
@include "home_page";
@include "welcome_page";
@include "account_page";
@include "blog_post";
// global styles here…
|
My files are organized into separate, logical pieces yet end up in a single production file. For debugging purposes, most preprocessors provide the option to add comments to your compiled CSS, including filenames and line numbers of the source file.
2. Create variables to make your code more readable/writable
Hexadecimal and RGB codes are unreadable, yet we use them to describe colors in our otherwise English-looking CSS files. My mind doesn’t recognize “#737373″ as “dove gray,” so writing color directives often becomes an exercise in hunting for prior use and looking up the values in a Photoshop color wheel.
With SASS variables, color codes can be stashed in a separate file and given human-readable names. It’s a small gesture but goes a long way toward code readability. Expressing your site’s color palate in one set of SASS variables delivers the additional benefit of corralling them in a single place. This allows us to make adjustments in a single file instead of running a global find-replace:
|
1
2
3
4
5
6
|
$my-site-red: #f61010;
$my-site-blue: #1b10f6;
$my-site-green: #0ce23e;
a { color: $my-site-red; }
h1, h2 { color: $my-site-blue; }
|
3. Be a programmer and create mixins
For common sets of CSS rules, create mixins to save time. Take the example of drop shadows, a now ubiquitous CSS3 technique. Because older browsers each had different directives for this style, a slew of cross browser fallbacks are required to consistently pull them off. With the following mixin, we can abstract the cross browser directives and dry up code in the rest of the stylesheets:
|
1
2
3
4
5
6
7
8
9
10
|
@mixin base-dropshadow {
box-shadow: 6px 6px 6px -6px #CFCFCF;
-webkit-box-shadow: 6px 6px 6px -6px #CFCFCF;
-moz-box-shadow: 6px 6px 6px -6px #CFCFCF;
-o-box-shadow: 6px 6px 6px -6px #CFCFCF;
}
.modal-dialog {
@include base-dropshadow;
}
|
Taking it a step further, add parameters (and default values) to your mixins to make them more flexible:
|
1
2
3
4
5
6
7
8
9
10
|
@mixin border-radius(vert:4px, horiz:4px) {
-webkit-border-radius: $vert $horiz;
-moz-border-radius: $vert / $horiz;
-khtml-border-radius: $vert / $horiz;
border-radius: $vert / $horiz;
}
.modal-dialog {
@include border-radius (10px, 10px);
}
|
4. Use nesting and parent selectors to better organize your styles
A great way to make your code more readable is to take advantage of SASS’s nesting syntax. It more clearly follows the hierarchal nature of HTML, and neatly encapsulates style ideas
|
1
2
3
4
5
6
7
8
9
10
11
|
nav.utility-bar {
ul { list-style: none; }
li { display: inline-block; }
a {
display: block;
padding: 6px 12px;
text-decoration: none;
}
}
|
5.Use extend/inheritance as an alternative to utility classes
Projects often include a set of generic styling CSS classes for common style applications. For example, a class called “list-unstyled” might be created to remove padding and bullet points from a traditional <ul> element. This class makes applying styles to new markup easy, but overusing them can clutter your markup. SCSS allows you to extend the directives of these classes to the selectors of those elements that should always be styled this way. Consider the example below:
|
1
2
3
4
5
6
7
8
9
10
|
.list-unstyled {
margin-left:0;
list-style:none;
}
nav.megamenu {
ul {
@extend .list-unstyled
}
}
|
Now all <ul>s within the megamenu will inherit the styles of the .list-unstyled class, eliminating the need to rewrite the same rules or to apply the class in markup.