About

The CSS Lint Rules

Parsing errors should be fixed

By default, CSS Lint shows any parsing errors. Parsing errors usually mean you mistyped a character and may cause the browser to drop your rule or a property. Parsing errors are presented as errors by CSS Lint, the most important issues to fix.

adjoining-classes Don't use adjoining classes

Adjoining classes look like .foo.bar. While technically allowed in CSS, these aren't handled properly by Internet Explorer 6 and earlier.

empty-rules Remove empty rules

Any rule that doesn't contain any properties, such as:

.foo {}

A lot of times, empty rules appear as a result of refactoring without further cleanup. Eliminating empty rules results in smaller file sizes and less style information for the browser to deal with.

display-property-groupingUse correct properties for a display

Even though you can define any group of properties together in a CSS rule, some of them will be ignored due to the display of the element. This leads to extra cruft in the CSS file. The list of properties that CSS Lint checks for are:

display: inline should not use width, height, margin (and all variants), padding (and all variants), or float.
display: inline-block should not use float.
display: block should not use vertical-align.
display: table-* should not use margin (and all variants) or float.

Removed the ignored or problematic properties decreases file size and improves performance.

floats Don't use too many floats

Using float for layout isn't a great idea, but sometimes you have to. CSS Lint simply checks to see if you've used float more than 10 times, and if so, displays a warning. Using this many floats usually means you need some sort of abstraction to achieve the layout.

font-faces Don't use too many web fonts

Web fonts are growing in popularity and use of @font-face is on the rise. However, using web fonts comes with performance implications as font files can be quite large and some browsers block rendering while downloading them. For this reason, CSS Lint will warn you when there are more than five web fonts in a style sheet.

shorthand Require shorthand properties

Sometimes when editing a rule you may end up defining multiple properties that can better be represented using shorthand. This rule checks to see if you're using margin-left, margin-right, margin-top, and margin-bottom together and suggests to use just margin instead. The same is done for the variants of padding.

font-sizes Don't use too may font-size declarations

A site is typically made up of a finite number of font treatments, including font size. If you have 10 or more font sizes specified, you probably want to refactor into a standard set of font size classes that can be used in markup.

ids Don't use IDs in selectors

IDs shouldn't be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It's much preferred to use classes in selectors and then apply a class to an element in the page.

qualified-headings Don't qualify headings

Heading elements (h1-h6) should be defined as top-level styles and not scoped to particular areas of the page. For example, this is an example of an overqualified heading:

.foo h1 {
    font-size: 110%;
}

Heading elements should have a consistent appearance across a site.

unique-headings Heading styles should only be defined once

Heading elements (h1-h6) should have exactly one rule on a site. CSS Lint warns if it finds more than one.

zero-units Zero values don't need units

An easy way to save bytes in CSS is not include units when a value is 0. For instance, 0px and 0 are the exact same measurement, so leave off the units and save!

vendor-prefix Vendor prefixed properties should also have the standard

When using vendor-prefixed properties such as -moz-border-radius, make sure to also include the standard property. The standard property should preferably come after the vendor-prefixed one, such as:

.foo {
    -moz-border-radius: 5px;
    border-radius: 5px;
}

gradients CSS gradients require all browser prefixes

Right now, there is no standard CSS gradient implementation, which means using CSS gradients in a cross-browser way requires using many different vendor-prefixed versions. CSS Lint warns when a rule with a CSS gradient doesn't have gradients for all supporting browsers.

regex-selectors Avoid selectors that look like regular expressions

CSS3 adds complex attribute selectors such as ~= that are slow. When using attribute selectors, don't use the complex equality operators to avoid performance penalties.

box-model Beware of broken box models

Borders and padding add space outside of an element's content. Setting width or height along with borders and padding is usually a mistake because you won't get the visual result you're looking for. CSS Lint warns when a rule uses width or height in addition to padding and/or border.

importDon't use @import

The @import directive prevents some browsers from downloading resources in parallel (see: Don't use @import)

important Don't use !important

Using !important overides any cascaded rule and may lead to specificity war. CSS Lint checks if you've used !important, and if so, displays a warning. If there's at least 10 !important declaration in your code CSSLint displays an error.

compatible-vendor-prefixes Include all compatible vendor prefixes

Most CSS3 properties have vendor-prefixed equivalents for multiple vendors, including Firefox (-moz), Safari/Chrome (-webkit), Opera (-o), and Internet Explorer (-ms). Including all compatible vendor prefixes will give a consistent appearance for a wider range of users.

duplicate-properties Avoid duplicate properties

When you include the same property twice, it may be intentional (to provide a fallback) or unintentional (copy-paste error). If duplicate properties are found one after the other with different values, this is okay. For example:

.foo {
    background: #fff;
    background: rgba(255, 255, 255, 0.5);
}

However, if the properties either have the same value or are located at different spots in the rule, this results in a warning. For example:

.foo {
    background: #fff;
    color: #000;
    background: rgba(255, 255, 255, 0.5);
}

Contribute

Many people have expressed an interest in contributing to the CSS Lint project. We were waiting to have a solid plugable architecture and API before taking contributions. The exciting news is that we are now ready! There are several ways you can contribute:

If you are comfortable with CSS, submit rule ideas. You must provide the rule name, a human readable explanation, browsers affected, and a test case.
If you are comfortable in JavaScript, fork the github project, code up a rule, and submit a pull request. You'll need to provide all the same documentation requsted in item 1.
If you are comfortable with Node or Rhino, test out the command line version, submit feature requests.

CSS Lint Command Line

There are two options for using CSS Lint on the command line. First, if you have Node.js and npm installed, you can install CSS Lint easily using the following:

sudo npm install -g csslint

If you prefer to use Rhino instead, grab csslint-rhino.js.

Both the Node.js and Rhino command line interfaces work the same way. Run them and pass in any number of CSS files or directories containing CSS files. For Node.js:

csslint test.css dir_of_css/ test2.css

For Rhino:

java -jar rhino.jar csslint-rhino.js test.css dir_of_css/ test2.css

You'll receive the same errors and warnings as you would with the web interface.

If you'd like to customize the rules that the command line uses, do set by setting the rules= option and passing a comma-separated list of rule IDs. For Node.js:

csslint --rules=ids,important,import test.css