CSS Lint, harmful or useful?

Published Monday, October 24, 2011 7:35 PM

While they say closed garden is the lending trend in internet, to me, the internet still feels like an ever expanding infinite loop, or maze. Like a little kid, I really start out just to search for a shiny pebble, I end up going far and away and lost. I end up with a pocket full of things I am excited and confused about.

Finding css lint is like that. I was looking for some basic css truth, then along the way I read a dozen of other articles, css related or not. Then I stumbled into css lint. So I copied and pasted from my reportoire of css files, linted it. Wow, it threw up a vocano of warnings at me.

Source: Screen Shot of CSS lint of my css

Interesting. I scanned through them.

"Values of 0 shouldn't have units specified"; "Broken box model: using height with padding"; "Rule is empty" ...

Make sense, I was thinking, almost delighted. Wow, this could be my css "spell-check".

Then I was confused by other rules. "Don't using adjoining classes", "Don’t use IDs in selectors".

Really? What is wrong with using IDs in selectors?

A little search quickly led me to this highly provocative article CSS Lint is harmful, followed by fifty or so comments, mostly of them is a bit spiteful in tone.

So What are the CSS lint rules?

  • 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 elements should have a consistent appearance across a site.
  • 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

Source: Introducing CSS Lint

Among them, the most attacked is the rule of "Don’t use IDs in selectors".

"To suggest that you never use ID’s is simply throwing the baby out along with the dirty bath water. ID’s are extremely useful and you absolutely should use them. They are the fastest way a browser can select a given element. They are useful for in-page anchoring and if they’re already there in the markup then use them as style hooks. They are also, oddly enough, perfectly correct to use as long as they’re only ever one instance of that ID on any given page."

Source: CSS Lint is harmful

On with my search. I found a lot of people have dismissed this rule. As it is with almost everything, never say never. Reasons are probably: 1) it has been a common practice; 2) ID by definition is mean to be unique, therefore there is no ground for re-usability concern. And, what is the difference using ID selectors and class selectors.

However, there are also as many people as passionately depending the rule. Using ID selectors lead to a downward spiral into specificity; IDs are meant to be specific, yet css rules by default are meant to be abstract rules.

So my search got me into a heated debate as with so many aspects of the web, jQuery vs. Ext Js, Flash vs. Html5. So I decided to end my aimless wondering in this maze by ending the search, and take away home my rules:

1) css lint is not all evil or good, it is a good tool for you to get your css cleaner. Yes, always true are rules such as "no empty rules", "zero values need no units".

2) The "too many" rules are to your discretion. Only you should know whether there are too many fonts, too many floats. However, it is good to have a second opinion.

3) IDs in css selectors may not be too bad, at least probably not worth your effort of going back and rewriting your pass css rules. However, when you start a new project, when you find yourself define a set of rules just for one unique ID, think again.

by xxxd
Filed under:


No Comments

This site

This Blog



  • MaximumASP