Should You Start Using CSSLint?

Getting our code reviewed by a pro is a great way of improving code quality but what happens if you don’t have access to a rockstar programmer? You do the next best thing and grab a ‘lint’ for that language.

Today, I’d like to talk a little about CSSLint, a recently released code analysis tool for, you guessed it, CSS. Join me after the jump!

What Exactly is a Lint?

Let’s hit Wikipedia for a definition:

Lint is a tool that flags suspicious usage in software written in any computer language.

Basically, a lint looks at our code and checks for bad programming practices. Undefined variables, inefficient constructs, things like that.

You’re probably wondering why you’d ever need such a tool. Let’s face it: not all of us possess supreme knowledge of what we’re working with or have the luxury of getting our code peer reviewed. In these cases, sticking our code in a lint is the next best option. And unlike clean up tools, lint spits out tidbits about your code and how to improve it.

Introducing CSSLint

Created by Nicholas Zakas and Nicole Sullivan, CSSLint is an open source tool that checks your syntax against a set of predefined rules to root out possible inefficiencies and make sure that your presentation works as expected with little surprises.

After heading over to the CSSLint site, you can merely paste in your source CSS and choose which rules you’d like enforced. Hit the lint button and CSSLint will start eroding your smugness.

If you’re a Node junkie like me, there’s a version for that as well. Just type in sudo npm install -g csslint and you’re good to go!

The CSS Lint Rules

Let’s take a quick look at the rules that CSSLint enforces.

• 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
• 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
• Don’t use @import
• Don’t use !important
• Include all compatible vendor prefixes
• Avoid duplicate properties

If you’re anything like me, a few of the rules must have had you flummoxed.

Do the Rules make Sense?

Quite frankly, yes, no and everything in between.

After lurking at a number of discussion boards and IRC rooms, I found out that many developers seem to be in uproar over the rules and maybe right so. Let me attempt to explain why most of the rules make sense but others do not.

The Controversial Rules

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.

This one struck a nerve with a lot of developers since we’re quite accustomed to assigning IDs for the main structural components of a layout like the header and footer.

CSSLint argues that the styling for such elements, by definition, can’t be directly reused. If you want dual sidebars on your page, a class lets you reuse styling while an ID will not.

Keep in mind that just because a class can be reused doesn’t mean it has to be. Unique classes are perfectly acceptable and a swell way to reuse styling if the need arises.

Don’t qualify headings

Heading elements (h1-h6) should be defined as top-level styles and not scoped to particular areas of the page.

Most developers, including me, have gotten used to writing context sensitive headers. As in, we define separate styling for headers depending on, say, which page it is being displayed on. An argument in favor of this approach is that it moves all cruft from the markup to the stylesheet. You can merely define a tag and let the CSS cascade accordingly.

CSSLint argues that such an approach compromises the predictability of your design. If someone else were to pick up your design and tried putting in a heading somewhere, he/she would need to be aware of the context and placement of the element. With headings defined unconditionally, he or she can use a heading anywhere confident of its presentation regardless of its parents.

Heading styles should only be defined once

Heading elements (h1-h6) should have exactly one rule on a site.

An extension of the rule above to improve predictability of presentation. Right or wrong, keep in mind that this basically excludes including some sort of reset code within your stylesheet. Every reset sheet works on your headings as well and thus CSSLint will mark it as an error.

The Questionable Rules

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.

With this rule enabled, CSSLint flags rules like .nav.red, with the official reason being that Internet Explorer 6 and below don’t play well with the selector. I respect the developers but I have to disagree here. Just because it doesn’t work with Internet ‘Dev-buster’ Explorer 6 is not a great reason to stop working with a useful feature.

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.

The box model maybe broken but almost every front end developer I know is intimately aware of the shortcomings and how to overcome the disparities with implementation. Are we really ready to give up a layer of control because some older browsers have a different implementation?

Don’t use too many web fonts

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.

I don’t foresee a situation where I’d be using more than five fonts in a page but I feel that dipping into this territory is a bit questionable. If anything, this is a design flaw than a development flaw. If a developer is referencing five separate fonts in his stylesheet, chances are, it ain’t by accident.

Don’t use too many floats i.e. abstract the functionality away

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.

While I concur with the creators’ argument that having more than ten instances of float is a bad idea, I also feel that this will affect the markup once past a given size.

For example, in a situation where you’d want to float two elements, traditionally you’d use:

<div class="container-1"></div>
<div class="container-2"></div>

… and the styling, by traditional methods.

.container-1 { width: 70%; float: left; }
.container-2 { width: 30%; float: left; }

The CSSLint method would be abstracting the float like so:

<div class="container-1 float"></div>
<div class="container-2 float"></div>

… and styling like so:

.container-1 { width: 70%; }
.container-2 { width: 30%; }
.float { float: left;}

While I agree that this is a viable approach, I feel that the markup will get significantly crowded once you try to abstract more away. I’d rather see a class containing most of its styling in one place than clutter the markup with 10+ classes. Again, I feel that this is a subjective topic.

The Obvious Rules

• Remove empty rules
• Avoid duplicate properties
• Zero values don’t need units
• Vendor prefixed properties should also have the standard
• Parsing errors should be fixed
• Include all compatible vendor prefixes
• … rest of the rules

All of the rules above adhere to the current standard practices. Sure, some of the rules have little real world significance, like zero values not needing units, or will be caught by a decent IDE, like parsing errors, but nevertheless these are good rules to have in a CSS test suite.

A Few Concerns

CSSLint is going to help a lot of developers down the road but…

CSSLint is, no doubt, written by developers with great credentials and is definitely going to help a lot of developers and designers down the road.

What I find a little irksome is that a lot of the controversial rules come from Object Oriented CSS, a CSS framework intended to let developers write maintainable CSS. While I have nothing against the framework, and its paradigm, you’d have to agree that it’s a way of doing things, not the way to do things.

As opposed to JSLint where I feel like all the rules make sense, with CSSLint, it feels like I’m being told that one style of writing CSS is right and the others are wrong. It’d be like someone asking me to give up the Beatles because Rolling Stones is their preferred band.

It’s Only a Tool

Tools are just that — tools.

Of course, we, as a group, tend to be rather clingy when it comes to our code. We don’t enjoy hearing that our code could have *gasp* potential issues or be written in an entirely different way.

The main thing to make a note of here is that CSSLint is, ultimately, a tool. It merely lets you know that some of the areas may have errors.

CSSLint doesn’t have to be the iron fist around which you base your entire ego on. There’s no reason to bend over backwards to avoid a warning if you know precisely what you’re doing.

So, Should you Start Using CSSLint?

Yes.

In CSS, as in integral calculus, there are many solutions to a given problem. There necessarily isn’t a ‘best’ way to do things — you may favor readability while I may favor efficiency. What’s important is that you realize that each and everyone of us have our unique way of doing things.

If you don’t have the same perspectives towards solving a problem, you may disagree with another approach and may even find it questionable.

Having said that, there’s never a good reason for not learning new things. Looking at problems from the perspective of another developer is a great way to see if you can learn something new.

Wrapping Up

What do you think about CSSLint? Find it useful? Confusing? Has it helped with your real world problems? Let us know in the comments.

Be excellent to each other and thank you so much for reading!