What’s Up with the Ban on CSS ID Selectors?

I’ve seen an idea that appears to be gaining momentum: banning the usage of ID selectors in CSS. When I first saw this, I assumed it was the ramblings of a single individual that was venting over an inherited project where ID selectors were being abused, but I’m seeing it pop up more often, and it has me a little concerned. Fortunately, there are some people that are stepping up to show the problems with this idea, and I thought I’d join in. Here are a few quotes I’ve found that I’ve decided to address.

IDs are almost always against the DRY (don’t repeat yourself) principle. For styling, you can always used classes which make your code much more reusable. I personally have stopped using IDs and I believe using IDs is a lazy bad practice, but yea still “valid”.

Yes, IDs are not meant to be repeated! It seems that this is the biggest complaint against ID usage, and what’s funny is that it’s the way the CSS language is meant to work. An ID is a “one-off”. You use it when you are certain you’ll never need it again.

As for being a “lazy bad practice,” I’m a bit confused. If you’re using IDs out of laziness, you may as well use the !important keyword or inline styles. Good CSS coders don’t use IDs because they’re lazy; they use them because the situation calls for it.

I’m totally on the “never use ID’s” thing. If you are having a specifity problem, using a selector that infinitely more powerful than a class is a sledgehammer approach when you need a knife…

…and a class selector is infinitely more powerful than a tag selector. What’s your point? That’s the nature of CSS. You don’t see people trying to advocate a ban on classes for that reason. A knife is great for things that require a knife, but a blanket ban on IDs, is just like a blanket ban on sledgehammers. What happens when you need to tear down a wall? It’s going to take quite some time with that little knife.

The point is that you use the right tool for the job. IDs have their place in CSS and so do classes. Not knowing when to use them is not an excuse for removing them entirely. There will always be developers that use the language inappropriately, and telling them to ignore (or even ban) specific aspects of the language is a detriment to their learning experience. It doesn’t make them better coders, and it contributes to the number of “professionals” that know very little about their field.

I firmly believe that crafting CSS should always focus on re-usability, it should be about creating patterns instead of one-offs. IDs are unique by nature and so work inherently against this. No matter how much you think you’ll only ever use a pattern once, somewhere down the line you’ll find yourself needing it again.

Again with re-usability. CSS that is specific to one website should not be reusable. That’s what CSS frameworks/boilerplates are for. If you find yourself writing the same CSS for every site, then you should probably move it to your framework CSS. If you follow this design pattern, then the unique nature of IDs is perfectly plausible and very helpful. Otherwise, you run into design nightmares trying to override the specificity of your framework CSS with multiple class declarations. CSS such as the following is confusing and a pain to maintain:

.home-page .row .span-6 header nav .link { ... }

Especially when an ID selector does the job, while being more concise and clear:

#home-menu a { ... }

If you find that somewhere later down the line you needed a class instead of an ID, then you didn’t properly plan the structure of your website. Now, I understand that no one is perfect, and in the real world things change, but, that should be the exception and not the rule. Let’s be clear: ID selectors should only be used for areas of a web page that will never appear on the page more than once. If you aren’t sure, use a class — but don’t blame ID selectors for your poor planning.

I have a blanket-ban on IDs in CSS. There is literally no point in them, and they only ever cause harm.

Wow. I can think of multiple reasons to use ID selectors, and it’s very rare that they cause me harm. I really can’t believe that an experienced web designer would even try to validate such a claim, considering that the vast majority of websites make use of ID selectors regularly and have been doing so for many years. “No point?” Clearly, you’re in the minority, as most web experts are finding a purpose for them.

As for causing harm, the only reason that makes sense is if you aren’t using them correctly. This reminds me of the sledgehammer example; use the right tool for the job. Consider this: I have a div with an @id of “logo”. This div will appear once on each page. Using an ID selector is perfectly acceptable. Now, for the sake of argument, suppose I had used a class of “logo” instead. A year from now, this website is inherited by another developer. He needs to make some changes to the logo, but he sees that it uses a “logo” class. Hmmm… should he go ahead and reuse the “logo” class? Who knows? To his knowledge that may be a class that’s used on some other obscure page he doesn’t know about, and making an update would be a risk that bites him later. After all, that’s how classes are supposed to be used. So, what does he do? He either adds another redundant class or writes some weird specificity rule to make sure that he’s only targeting the logo he wants. Using an ID would have made this quite simple — it’s an ID, it’s unique, and it has a clear purpose.

What bothers me the most is that supposed experts in the field of CSS are putting their seal of approval on this idea. Requiring members of your web team to avoid the use of a popular language construct because they may use it incorrectly means that you freely admit your team members are not experts and you never expect them to be. What’s the reasoning behind this? Some programmers have a hard time with C# delegates. Let’s ban them! Some designers don’t know when to use the <address> tag. Let’s ban it! Some coders don’t know when to use single/double quotes in PHP. Let’s require double quotes for everything! Ignorance is not an excuse for limiting your toolset. IDs are a part of CSS for a reason. If you have a hard time with them, then either learn when to use them or let someone else do it. But please don’t push your nonsense on everyone that does use them effectively.

If anyone has a valid use-case for banning ID selectors, let me know. I’ve yet to hear of one, but I’m certainly open to discussion.

Using Sass in Windows

If you’re reading this post, I will assume that you are already familiar with Sass. If not, it’s a CSS pre-processor, which adds support for variables, selector nesting, and other features to your CSS styles. See the Sass website for more information.

Here’s how I use Sass with my development process. There are many ways of integrating it into your workflow, so feel free to play around when you’re more comfortable. Your first step is to install Ruby.

Installing Ruby

Visit the Ruby Installer website to get the latest installer for Windows, and go ahead and complete the installation. When it asks about adding Ruby executables to your PATH, check the box. Otherwise, you will need to type the full directory path to execute the Ruby program. It’s also a good idea to associate .rb and .rbw files with Ruby. The installation should complete without the need for any other input.

Installing the Sass Ruby Gem

Now that Ruby is installed, it’s time to install Sass. Sass is packaged as a Ruby “gem,” and gems are basically programs that rely on Ruby to run. We’ll be using Sass from the command line, so open a command prompt (Windows key + R, then type cmd and press OK). Let’s make sure that Ruby was installed correctly by typing ruby -v and pressing Enter. If the version number that you installed appears, then you’re good to go.

To install Sass, type gem install sass and press Enter. Hopefully, everything went well, and now it’s time to start using it.

Sass Workflow

The two major workflows that I’m aware of are:

  1. Using Sass locally for development and deploying CSS to the production server
  2. Deploying Sass to the server and relying on server code to translate it into CSS before serving it up to website visitors

Obviously, the second process is a bit more complex, so we’ll focus on the first — but feel free to investigate further if the other workflow is more appealing to you.

I create two directories in my Web projects: one called “scss” for my .scss (Sass) files and one called “css” for my final, minified CSS files. To make the translation from Sass to CSS simple, we’ll use the --watch modifier in the Sass command line tool to automatically handle the translation any time we save our Sass files. Assuming you’ve created these directories and started your own .scss file in the “scss” folder, you’ll need to open your command prompt and change to your project directory (e.g. cd C:\Users\username\websites).

Next, enter the following command:

sass --watch scss:css

It should respond by saying, “Sass is watching for changes.” Go ahead and make some updates to your Sass file, save them, and check your “css” folder to see how Sass is automatically translating your Sass code into CSS. When you’re done, hit Ctrl+C in the command prompt and enter “y” when it asks to terminate the batch job to stop Sass from watching for changes.

One more thing: your CSS code should really be minified/compressed before deploying to the server. You can do this with the --style modifier. So instead of the earlier command you entered, use the following:

sass --watch scss:css --style compressed

There are many other things you can do with the Sass command line tool, but this is a good starting point, and should be just enough to start using Sass in your own workflow.