May 21, 2012

How to write a well structured CSS – Part II

In this part 2 of “How to write a well structured CSS”, we will focus on the important yet sometimes forgotten aspects of writing CSS. The areas that I would like to outline are:

Know the CSS Specificity and inheritance rules
CSS Lint
Commenting
Beautification: ensuring that the CSS code that is written follows a coding standard for example curly bracket placement or indentation
Use of pre-processors like SASS, COMPASS, LESS, and STYLUS

To review the topics that were discussed in part one of this post,the rules were:

DRY – Don’t Repeat Yourself. This means taking advantage of the cascading rules of the stylesheet and writing the minimal amount of CSS in order to apply the styling.
Performance – to keep the CSS file lightweight, the above rule (DRY) is very important. Consider the CSS specificity and inheritance for better performance (there is a great article on Smashing magazine regarding CSS Specificity). Also minimizing and removing comments is also important, therefore running the CSS through a minification process can help in keeping it lightweight.
Know when to place all CSS styles in a single file and when to break up modular portions of the CSS into it own CSS file.
Follow front end development separation of concerns tightly which means that everything that concerns presentation styles should be in the CSS (and only in the CSS).

We had also outlined a few guidelines:

Start with a reset or normalize CSS
Set default values
Follow the DOM
Class begins

Note: In regards to the “Class begins” guideline where we talked about creating classes as they are needed for styling. This concept follows the rule of single responsibility principle. Harry Roberts of csswizardry.com wrote a great article regarding the single responsibility principle applied to CSS.

Continuing with further CSS guidelines:

CSS Specificity and inheritance

I am not a big fan of using “!important” in a CSS file. I know that it exists, what it is used for, and I know that at times it is necessary. I believe that every CSS file should get a limit of 10 applications of ‘!important’ in it (even less for small sites), and any overuse of this rule by a developer is to be considered heretical and may cause the revocation of their CSS badge.

CSS specificity and inheritance is what the “cascading” definition in CSS is all about. Used correctly and it will help not only facilitate better writing of CSS but it will also help in debugging an errant CSS style.

Although this is not a simple concept to grasp, however if there is any recommendation I can make is that – LEARN AND UNDERSTAND THIS CONCEPT!! Here are some really great reference material:

CSS Specificity: Things you should know http://kiano.sh/MnDQm2
CSS Specificity and Inheritance http://kiano.sh/MnDVpX
Specifics on CSS Specificity http://kiano.sh/MnE0K0
Specificity calculators:
- Star Wars approach http://kiano.sh/MnE64m
- Poker game approach http://kiano.sh/MnE8cL

CSS Lint

CSS Lint a tool written by Nicole Sullivan which validates CSS code. This is great tool to ensure that your CSS code is valid. I have used this in the past to consistently validate my CSS code. On the major benefits of this tool is that it can also be run from the command line and incorporated into the build system (https://github.com/stubbornella/csslint/wiki/Command-line-interface)

Comments

As deadlines approach, sometimes developers cut what may be considered non-essential processes, “comments” are one of them. I know this because I am guilty of it. As we know when the deadline passes and with further development, we touch and review old code; there are times when we ask out loud “Why did I write this code this way?” (this point is 1000 times exasperated when trying to read someone else’s code).

So make commenting in all aspects of coding an essential habit.The approach I take for commenting is as follows:

Add comments to outline a section. To indicate the beginning and the ending of a certain section.

/* ==|== primary styles =====================================================
 All CSS pertaining to the site will go here. Also keep in mind that any mixins created
 will go in '_mixins.scss' file. All functions will go in the specific functions file labeled
 '_<function_name>.scss
 Author: Kianosh Pourian

Comment Legend
 prefix = tpl = Template Styles

================================================================== */
/* CSS code will go here */

/* ==|== end primary styles ========================================== */

Also use comments to explain some of the classes, how, and even where they should be used

/* ==|== header classes ======================================
 These classes apply to the header. They are as follows:
 1. tpl-subBrand: sub-branding section of the site. Located on the top left.
 2. tpl-userInfo-linear-gradient: class to apply gradient to the element.
 3. tpl-userInfo-Cont: container showing logged in user's information.
   a. tpl-userInfo-photoCont: container showing the user's photo.
   b. tpl-userInfo-first & tpl-userInfo-las: borders flanking the user
     information section.
 ============================================================== */
.tpl-subBrand {
   @include add-margin(all, 7px 0 0 10px);
}
.tpl-userInfo-linear-gradient {
   @include linear-gradient(top, #405979 0%, #334455 100%);
}

.tpl-userInfo-Cont {
   height: 55px;
   width: 315px;
   @include add-border(all, 1px, solid, #121212);
   @include add-border-radius(all, 5px);
   @include add-margin(all, 15px 15px 0 0);
   @include box-shadow(false, 0, 0, 6px, 1px, #121212);
   a {
     background: url("../img/sprites/coreSprite.png");
   }
.tpl-userInfo-photoCont {
     background: #333;
     height: 40px;
     width: 40px;
     @include add-border(all, 1px, solid, #2b2b2b);
     @include add-border-radius(all, 3px);
     @include add-margin(all, 7px 30px 0 0);
   }
   .tpl-userInfo-first {
     left: 0px;
     @include add-border-radius(top-left, 5px);
     @include add-border-radius(bottom-left, 5px);
     @include box-shadow(true, -4px, 0, 6px, -3px, #000);
     a {
       background-position: -0px -0px;
     }
   }
   .tpl-userInfo-last {
     right: 0px;
     @include add-border-radius(top-right, 5px);
     @include add-border-radius(bottom-right, 5px);
     @include box-shadow(true, 4px, 0, 6px, -3px, #000);
     a {
       background-position: -20px -0px;
     }
   }
}//end .tpl-userInfo-Cont
/* ==|== end header styles ================================== */

Inline comments should be used sparingly and as needed.

Beautification (coding standards)

Following a coding standard will not only make the code more readable but also help in finding issues faster. Proper indentation and syntax highlighting should be set and followed. There are several CSS beautifier tools that can be used for this effort or better yet, as you are coding ensure that you are following the coding standards that has been agreed upon. Here are some CSS beautifiers:

To pre-process or not to pre-process, that is the question

There are different views about whether to use pre-processors like SASS, COMPASS, LESS, STYLUS, etc… This article is not about convincing you in one way or another (more talks about pre-processors coming up in other blog posts). Frankly in order to write a well structured CSS, the use of pre-processors is not necessary. However in regards to using pre-processors, I will give the following advice:

Know your CSS: pre-processors are only tools that only help in writing CSS proficiently; what it will not do is write proper CSS. So know CSS well, whether you are using pre-processors or not.
Another tool in your arsenal: Pre-processor like SASS and LESS give writing CSS a new dimension of dynamic coding which did not exist. In my humble opinion, anything that can help in making writing CSS easier and more robust is aces in my book.
One last point: Use them! I have been using SASS for the past year and I really have enjoyed it. It has made the process of writing CSS very fluid and easy.

An Innovatory Life