LESS / CSS Style Sheet coding standard

First off, HTML should be semantic. There should be no styling in the HTML markup. There should be no <style> tags, as they will be difficult to override from external CSS.

There should be no style properties in any of the HTML tags. When these are used the only way to override them is to use !important.

!impotant should never be used. !important is like a jack-hammer, it punches a hole through the inheritance structure upon which clean CSS relies. You can’t build a house with a jack-hammer and you build a maintainable site using !imporant. If you do need to use !important, and can’t find any way around it, there should be a comment explaining right afterwards in detail why there was no other choice.

When you use these methods it just makes the work of the CSS developer more difficult. They are useful for injecting styles through JavaScript (JS) after the page is loaded but should never be included in the raw HTML. If styling needs to be inserted dynamically on the server, at the time of the request, it should be done by inserting semantic classes that implement styles in the style sheet.

Tabs should be used instead of spaces to indent lines. Using spaces makes un-identing cumbersome. When tabs are used the programmer can set the tab width larger or smaller depending on their personal preference and to compensate for the depth of the tab-structure. Tabs also make for smaller file sizes (but we’re compressing out uninterpreted white space anyways).

To increase readability, words in class-names should be separated_by_underscores, as opposed to camelCase or dashes.

All class names should be semantic. They should contain no aesthetic or visual visual references, such as .blue_rounded_box {}.

Classes should be used whenever possible instead of IDs, in order to simplify inheritance.

Each rules should be written on a new, single line with a space before the opening curly bracket, a space after each colon and semi-colon, but no spaces on the directly on the inside of the brackets.

This differs from the usual standard, but it makes it easier to find the selector you’re looking for with less scrolling around. In the usual format with each rule on a separate line, you end up with a very narrow column of information and everything gets too spread out horizontally to see the overall structure.

LESS

The big problem with CSS is that there is no inherent structure to the files. They’re just long lists of selectors with list of rules inside. When a new CSS developer comes to a project he will often just add style rules to the end of the file because he doesn’t want to mess up anything that’s already there. If he’s any good, he’ll find the selector and rule that he wants to edit, but there’s no obvious place place to put new selectors when they need to be added. The only way to structure things is by using block comments and maybe some tab structuring, but this is difficult to enforce in a large project with say six-thousand lines or more, and when the site is refactored, it becomes nearly impossible to remove all the dead selectors.

LESS is a dynamic, procedural language for creating CSS that is based on CSS. It’s elegant and resolves a lot of the issues of having to type the same thing over and over again, and it makes refactoring your styles a breeze. More information can be found at the LESS website, http://lesscss.org/.

The LESS website recommends linking directly to .LESS style sheets from the HTML and using the JavaScript interpreter on client side. However, this can be problematic. First, it goes against the concept of progressive degradation; if a user has JS disabled, or their client doesn’t support JS, or if there’s an error before the LESS stylesheet is interpreted, the page will fail to be styled. It places additional load on the user’s JS engine which can slow down performance. Finally, when the page loads it is displayed with no styling at first. Generally the interpreter is pretty fast, but if you have a long stylesheet the page might be displayed before it’s styled. For these reasons, I’ve decided that it’s best to compile the stylesheet first and send them plain old CSS. If you’re a linux type, you can just install less from the command line, as described on their site under server-side usage. For Mac OSX there’s a great compiler available at incident57.com/less and a Windows version at winless.org.

Don’t worry about it slowing down your process, it will compile the stylesheet in the background every time you save, and t will be ready by the time you switch to your browser to test. If you write an error into your stylesheet, the compiler will find it for you and fail. I found this pretty annoying at first. With plain old CSS my errors were just glossed over, and and everything else worked fine. But now I love it because I always catch my mistakes right away. You can think of it as an instant validator.

To minimize load times and server requests, the stylesheet should be served as a single, minified file. This is right out of the YUI guidelines. There should be one main stylesheet for each project/website. The main stylesheet should be named after the project or client to avoid any confusion.

The LESS compiler handles all the concatenation and compressions for you by default. Any file stylesheet I need to include, I convert into .less, just by changing the file extension. Then, use the @import directive in your main stylesheet for each extra stylesheet you need to add. For example you will often need to add third-party stylesheets:

@import "jquery-ui-1.8.16.less";

However, there is some invalid CSS in the jquery-ui stylesheet (as in most stylesheets) that will kill the compiler. The compiler will dies at rules with things like:

.ui-helper-zfix { width: 100%; height: 100%; opacity: 0; filter: Alpha(Opacity=0); }

…But the compiler will notify you exactly where the issue is, and it’s pretty quick and easy to find and escape these with:

filter: ~"Alpha(Opacity=0)";

Alternatively, if you don’t want to mess with all that, you can just escape the whole file. Now, you’re compiling and compressing like a pro. File Structure: First, there should be block quote at the top of every file to identify the file.:

/*
Document   : calumet.less
Company    : Simply Intereactive
Created on : Oct 20, 2011, 4:33:11 PM
Author     : Robert Williams 
Description:
This file is the main styling source for the calumet site. It should be
compiled and compress before serving the the client.
*/

Each subsequent block of code should have a comment before it preceded by a blank line. If any @font-face declarations are used, they should come immediately after the block quote.

/* @font-face declarations */
/* first for IE 4–8 */
@font-face {font-family: DINWeb; src: url("FF-DIN/DINWeb.eot");}
/* then for WOFF-capable browsers */
@font-face {font-family: DINWeb; src: url("FF-DIN/DINWeb.woff") format("woff";}

This will allow the browser to load the fonts while the CSS is still loading, thereby minimizing the dreaded FOUT. Next, comes the @import directives, all of which should all be .LESS files.

/* import styles */
@import “lib.less”
@import "normalize.less"; //normalize css
@import "jquery-ui-1.8.16.custom.less"; //ui-lightness modified for less

The first of these should be a lib.less file that includes all the standard utility mix-ins and functions that you will want for any project. Dash-separated words should used be reserved for mix-ins and functions when they are named after specific dash-separated CSS properties or values, such as .border-radius or .inline-block.:

/*
Document:   lib.less
....
Description:
This file is to hold some standard, generic utility functions and mix-ins.
*/

.border-radius (@radius: 5px) {border-radius: @radius; -webkit-border-radius: @radius; -moz-border-radius: @radius;
}
.box-shadow (@x: 0, @y: 0, @blur: 1px, @color: #000) {box-shadow: @arguments; -moz-box-shadow: @arguments; -webkit-box-shadow: @arguments;}
.inline-block {display: inline-block; _display: inline; zoom: 1;}
...

I recently discovered LESS Elements, which I am considering either including into my lib.less file or using in its place.

The second file, normalize.less is identical to normalize.css, which eliminates the need for a base.css and reset.css as prescribed by the YUI guidelines. http://necolas.github.com/normalize.css/The next block contains global variables specific to the entire site, such as the colors for their identitiy:

/* global variables */
@red: #ee3124;
@blue: #5cafdc;

Next, we have mixins. In LESS reusable aesthetic-named classes can be defined and then used as mix-ins for the semantic named classes. Example:

/* mixins */
.rounded_grey_box {background-color: #1a1a1a; .border-radius(8px); padding: 20px 10px; border: 1px solid @blue;}

Next, we have a block for base styles that includes all custom styles applied to html elements in the site. No classes or IDs belong in this section.

/* html elements */
body, html {font-family: DINWeb, helvetica, arial, sans-serif; font-weight: 100; background-color: #333; color: #fff; font-weight: 100; font-size: 16px;}
a, a:visited {color: #fff; text-decoration: none; outline: 0;}

The next block is /* global */, which should include styles that should be applied throughout the site. All the other blocks are for styles that are associated with a specific page (or section if applicable). The page name should be inserted by the server as a class on the <html> element automatically.

<html class="home">

…Thus, they can be immediately available when styling. All the styles that are applied to a specific selector should be written on the same line as the selector (see “html.home”). Each nested rule should be placed on a new next line down and indented one tab, such as the “h4″ here which sill expand to “html.home h4″. Rules that include nested rules should have their closing bracket place alone on a line indented to the same amount.

/* Home */
html.home {color: #ededed; background: url(../img/mountains_bg.jpg) no-repeat top center #666;
	h4 {color: @red;}
	.supporting {text-transform: none;}
	.sections {
		a {display: block; float: left; width: 30%; padding-left: 35px;
			&:first-child {padding-left: 0;}
			h2 {color: #fff;  display: block; font-size: 19px; line-height: 1; height: 28px; width: 265px; padding: 107px 0 0 10px; background: url(../img/lenses_bg.png) no-repeat;}
			h4 {font-size: 16px; text-align: right; padding-right: 25px; padding: 5px 25px 0; background: url(../img/double_angle) no-repeat right;}
		}
		a.simulator h2 {background-image: url(../img/simulator_bg.png);}
		a.decision h2 {background-image: url(../img/decision_bg.png);}
	}
} // end home

12 thoughts on “LESS / CSS Style Sheet coding standard

  1. I think this is one of the best things I have read. I’m glad that I saw your post. Can I point out a few things, The web site style is awesome, the posts are cooltop notch! :D . Good work, cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>