Why we’ll stop using ID in our stylesheets

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.

  • Anonymous

    That’s a good, balanced post. I *did* make some changes to my CSS after passing it through CSSLint, but I’m not changing everything it suggests. I’ve made far more radical changes to the interminable labyrinths that pass as stylesheets for the big popular CMSs. Although this appears similar to the validation fever that swept away a lot of badly-formed HTML, the difference is that the standards are not half as clear-cut. I just hope it gets rid of some bad practice.

    • Melanie Archer

      @DaveEveritt:disqus –I’m reminded more of the discussion surrounding the use of Web accessibility evaluators like Bobby. A lot of content owners were anxious to meet governmental accessibility requirements, and assumed that a good report from this software meant they were in 100% compliance–a false assumption, since accessibility requirements also have subjective qualities (what makes a good “text equivalent”?). 
      Yet, as you point out, online tools did encourage revamping a lot of bad markup.  Are we better off? Incrementally at best, judging from your example of CMS styling.

      • Anonymous

        Having worked through that period too (and advised clients in detail on accessibility) I think the similarity to Bobby is a good one. You can lay down certain requirements, but – beyond the fundamental necessities of the ‘ilities’, and outside plain bad practice – there’s an element of artistry about well-made markup that’s hard to capture in a generic set of axioms. That being said, there’s still good, bad and mediocre markup and plenty of bloated CSS out there, so let’s hope for a general improvement. Especially in style sheets longer than 400 lines, which is when the need for good structure becomes apparent, as it does in any code.

      • Anonymous

        Having worked through that period too (and advised clients in detail on accessibility) I think the similarity to Bobby is a good one. You can lay down certain requirements, but – beyond the fundamental necessities of the ‘ilities’, and outside plain bad practice – there’s an element of artistry about well-made markup that’s hard to capture in a generic set of axioms. That being said, there’s still good, bad and mediocre markup and plenty of bloated CSS out there, so let’s hope for a general improvement. Especially in style sheets longer than 400 lines, which is when the need for good structure becomes apparent, as it does in any code.

  • Thanks for the solid feedback!  I have to say that you are absolutely right.  Over-dependence on classes could be bad.  Maybe I need to update my post so it doesn’t sound like I am advocating the use of classes on every element in the DOM. 

    On the contrary, I’ve found that I’ve also gone full circle.  I’ve used a plethora of CSS3 techniques to essentially remove dependence on divs and class-itis.  However I have also found that in terms of re-usability of css, I usually have to add a few more classes.  Sometimes more than I am totally comfortable with.. but I’ll go with a few more classnames, and a smaller stylesheet any day.  
    Why?  With a 1 to 1 relationship that much of our css tends to have, this means that every new page, new module that ends up on the page, will add to our css.  And you know how tough it is to cut out css once it’s been implemented.  I once spent a week pulling orphaned css out of a huge site with a 500kb css file (compressed!)  I was able to remove 200k of dead css weight, but it took a week!
    Nicole Sullivan also gives some really good input here: http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/Feel free to hit me up on Twitter,  I am more than happy to talk in more detail and update my blog post with more detailed information.   😉

    • Yes, the dread problem of CSS cruft, something we’ll be dealing with a lot more as people start layering frameworks and plugins  and gotta-try-it techniques from the latest post on Smashing Magazine (this site no exception) 🙂

      I think the class selector will always be the workhorse. Just plain HTML element selectors have, as you mention, less utility every day.  CSS3 selectors are exciting and powerful–we’re almost to the point where we start by writing the CSS before the markup.

  • > 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.

    It would be a disaster for everyone who tries to do great css if clients were checking what we did with that tool, and would probably result in more awful markup.

  • Miriam

    I think the bias against using IDs in CSS may be left over from when the JavaScript was more likely to use IDs than class. There was an attempt to keep the JavaScript and CSS separate.  Now, with frameworks like jquery likely to use the class, it doesn’t hold true as much.

    There are convincing arguments for using an extra id or class at the start of each rule to scope to a whole section/page just so that it would be easier for many people to work on the CSS without adversely impacting other sections.  This is slower and bulkier, but if you are working on a large, crazy project with enough other people, this makes sense. (Unfortunately, I don’t remember where I read this, I think it was from someone from Google or AOL in a presentation.)

    http://csswizardry.com/2011/09/writing-efficient-css-selectors/  says the opposite of what many of us were taught, that it’s more efficient to add classes or ids to the markup and to use the IDs. This is the opposite of what you said lint said to do, and counter-intuitive to creating clean markup.

    So, I believe that one has to balance the requirements of the specific project.