CSS frameworks, architectures and best practices are a big focal point at the moment. Conference talks, social conversations and even opinion blog posts – this one ironically included.

As a lover of CSS, I can only encourage this – heck, if you need someone to come speak about CSS at an upcoming event, get in touch – but there is something that has been bugging me for a while; there seems to be a lot of negativity aimed towards ID selectors.

2011 saw the introduction of CSSLint, a service which allowed you to check your CSS against a number of recommendations and deemed ‘best practices’. A lot of people looked to this tool to better their CSS authoring skills, but without context these recommendations became law. Ones which we were adamant not to break.

One of these laws recommendations being ‘Don’t use IDs in CSS selectors’. Given to the user with, unfortunately, no real context. No education as to why this might be deemed as bad.

More recently, Harry Roberts (or @csswizardry as others might know him) has, in his own words, “vehemently recommended you avoid” using ID selectors. Whilst Harry goes on to explain his points and opinion further, I feel we are avoiding the fact that applied conservatively, properly and where applicable: IDs do have their uses. If that wasn’t the case, they would have been deprecated from the specification.

Going on to offer a solution of hashed CSS classes is, in my opinion, only covering up the problem and not educating our fellow developers on how to avoid the pitfalls that naturally come with ID selectors.

We all know that ID’s are reserved for unique elements – there should only be a single instance of an ID on any given page. Some may feel that you will rarely have an absolute unique item and that CSS is meant to encourage reusability, and I agree, but there are still instances where a unique ID is relevant and has its use.

An example would be a template identifier. When authoring a website, we build a number of templates, examples being; the home page, content page or news listing. These are all templates which are built up of our reusable class-name-based components, but sometimes you need that one unique identifier to hook into and make a change. Something that would only be applied to this one template e.g. a different background image.

Another example is the need to create a specific variant of a component. In this instance the base styles would be applied using our CSS class, but extra styling might need to be applied for a specific instance. An example of this would be a featured news feed built upon your default listing component.

ID’s make these possible.

Many people talk about and air their concerns about the specificity of ID selectors and the muddle this can get you in, and they are right. Applied without logic and practicality, you can quickly find yourself getting into specificity wars with yourself and this is where the use of !important creeps in.

However, applying the above logic of using class names as your base layer of styling and identifying your reusable components, we can then apply IDs in cases of absolute uniqueness.

By understanding the structure of your CSS, and considering the impact your selector will have, then I do not see why the ID selector cannot be a part of any developer’s arsenal.

So rather than disregarding them altogether – think about their application, use them conservatively and utilise them as a powerful tool.