Not too long ago, Nicole Sullivan and I announced that we’ve started working together. Today, we’re happy to announce the release of our first collaboration effort: CSS Lint. The goal of CSS Lint, as you may guess, is to help you write better CSS code. We’ve spent huge chunks of time over the past couple of weeks building and debating rules to help everyone write more efficient and less problematic CSS.

The rules

To begin with, we defined several rules (explained in more detail on the CSS Lint About page). The rules are:

  • Parsing errors should be fixed
  • Don’t use adjoining classes
  • Remove empty rules
  • Use correct properties for a display
  • Don’t use too many floats
  • Don’t use too many web fonts
  • Don’t use too may font-size declarations
  • Don’t use IDs in selectors
  • Don’t qualify headings
  • Heading styles should only be defined once
  • Be careful using width: 100%
  • Zero values don’t need units
  • Vendor prefixed properties should also have the standard
  • CSS gradients require all browser prefixes
  • Avoid selectors that look like regular expressions
  • Beware of broken box models

The rules are all created using a very simple plugin model that makes it easy to change specific rules or add new ones. The ability to turn off or on specific rules isn’t yet exposed in the web or command line interfaces but is supported by the underlying API, so look for this addition soon.

In your build…

While we’re happy to introduce the web interface, we also realized that you may want to incorporate this into your build system. To help, there is CSS Lint for Node.js. You can install the CSS Lint command line tool via npm:

sudo npm install -g csslint

Once installed, you can pass in any number of files or directories with CSS files:

csslint foo.css bar.css dir_of_css/

The tool then outputs the same information as the web interface.

Contribute

CSS Lint is completely open source and available on GitHub. We’re actively looking for people to contribute rules, bug fixes, and extensions. The rules, by the way, are completely pluggable. You can easily strip out rules you don’t want or add new rules that are more specific to your needs. Then, build a custom version that suits your needs or contribute the changes back.

The CSS parser that it’s built on is also open source and available on GitHub. There are some known issues with the parser that I’m planning on addressing soon, but it’s generally CSS3-compliant.

I hope Nicole and I will be able to make more tools of this nature to help everyone write better front-end code. Enjoy!

Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.