Seemed like everybody was talking about CSSLint a couple of weeks ago. I waited for the hype cycle to slow its rotation, then dutifully visited the online linter to pay my respects.
It didn’t repay them.
“Will hurt your feelings” is CSSLint’s tagline. Heh, heh; I’ve written stylesheets for thirteen years now. What faults could CSSLint find with my CSS?
Plenty, it seemed. Chief among the linter’s nagging judgments was my use of the ID selector in so many rules. Now, what’s so wrong with that? How is it that my practice for all these years is suddenly considered wrong?
I found this blog post proposing that the hip, up-to-date stylesheet of today contains no ID selectors. Intrigued, I posted the link on Talentopoly, where it generated a thread of comments from people who seemed indignant with the premise. Why discard a totally valid technique which can make one’s markup and CSS more succinct?
I think one reason we were so uneasy is that we’ve had to work with so much bad markup and styling written by people with poor understanding of the cascade. The result is overdependence on classes for style rules–a classic example would be a navbar with a couple dozen <a class="navLink"> bloating the markup. Expertly written CSS distinguished itself with terse rules attached to ID’d elements. But if you prohibit that, don’t you end up encouraging that stupid “class”-itis?
Perhaps. CSSLint can’t determine if your style rules rely too much on classes. But you can satisfy the linter’s criteria and also target specific elements without resorting to attaching class attributes to every node in your markup. For instance, you could show off your handling of CSS3 selectors instead.
Like JSLint, CSSLint is a tool based on its makers’ opinions of what constitutes good style. It’s not a validator, but an evaluator: it can suggest improvements (as did earlier linters). Using the linter is like getting the opinion of a haberdasher as to how wide your lapels should be: you’re not obligated to act on his advice, but you might look a little strange alongside your more fashionable peers.
But why has the ID selector fallen into disfavor?
Looking at the explanations on the CSSLint About page, I notice a pronounced concern for portable, modular styling. The linter discourages intensely specific selectors such as IDs and “qualified headers” (h* tags within a cascade, or with class attributes). There seems to be less focus on styling an entire, discrete page, and more on styling blocks of content which may be sent or received in an API. This is a reasonable emphasis: think of all the markup you’ve done in the last year. How much of it was for standalone pages? And HTML5 prods us to think of Web content in articles or sections, each with its own h1–our markup and styling are scraps, not whole cloth. It’s efficient to make them fit with others.
Well, so what–it’s just between CSSLint and you, right? No. A less obvious reason for abandoning the ID selector is so that your style rules pass CSSLint when somebody else submits your CSS to it. And this will happen. In a profession with no licensing and very little certification, front-end developers have few means of convincing potential clients that we know what we say we do. If our clients had the skill to inspect our CSS for quality, they’d probably wouldn’t need to hire us to write CSS for them. Tools like CSSLint, despite their basis in subjective opinions of good practice, reassure these clients: they know you’re following certain rules if you pass. They want the work you do for them to be rule-following and interchangeable, not idiosyncratic and difficult to reuse. Yes, a lot of terrible CSS can pass CSSLint–just as it can pass the W3C validator. That’s no reason to avoid using it.
