Quasi-qualified CSS selectors

This is a bit of an odd post in that the first half deals with qualified selectors, what they are and how they’re bad; the second half is more of a thinking-out-loud tip/trick than anything really substantial or interesting. Let’s see what you make of it…

One really basic way to make your CSS much nicer to work with is to avoid (over) qualified selectors. That is to say, it’s better to write .nav{} than ul.nav{}. This is for a variety of reasons, chiefly in that—with the former syntax—you can use .nav on anything at all, be that a ul or an ol and, secondly, it also keeps your specificity nice and low. Having an element prefixing the class selector bumps up its specificity unnecessarily and specificity is one of the easiest ways to get your project into a mess; keeping it as low as possible at all times is a very good idea.

For a decent (and very timid) example of how qualifying selectors impacts specificity, take a look at this fiddle. Here we can see that the qualified div.promo{} selector trumps the .special-promo{} selector. A sub-optimal fix would be to qualify the second selector. This is no good, because this will just go on and on and on… What we need to do is avoid qualifying selectors altogether.

So in short…

To start, a simple enough rule to follow; don’t qualify your selectors. This keeps classes element agnostic and keeps specificity low. Awesome!

Sometimes though, you can only really use a class on one element. A well abstracted class should be usable on a variety of elements, but oftentimes you have a class that can only ever really be used on one thing. How can you communicate this in your stylesheet without qualifying your selector? Let’s take an example…

Let’s say I have the media object in my project. The media object is element agnostic, as all good CSS should be. I know I can apply this to any element(s) that need to adopt that visual construct. This means my CSS only ever needs to read (actual styles omitted for brevity):


Here I don’t need to mark the classes for use on any specific elements because they can be used on (almost) anything. My CSS doesn’t care about my HTML and this is a very good thing.

However, what happens when I have a class like this:


Now, to look at, you can guess that this class probably belongs on a high-level container on a product page, but which one? The html element? The body? A wrapper div? The main content area? Well there are several ways I could communicate this to another developer (or myself, in six months time). Let’s, for this example, assume this class should be applied to my html element.

The first and most obvious solution to our problem might be do simply have this CSS:


Now I can immediately see that this class belongs on our html element. But here I have unnecessarily increased my specificity. Not by much, but by more than I need to, and more than I ever should. How can I tell the next developer that this class should only go on the html element?

Perhaps like this?

/* Apply this class to the HTML element on a product page. */

Which definitely works, but it’s a lot to write. A lot more than we need to, and you can’t glean that information at a glance.

A thing I’m considering starting doing is this:


I write the element in a comment so that it reads properly (a html element with a class of .product-page) but without altering the specificity at all.


The obvious problem with this is that, if you work in a team, you will have to make sure all devs understand and follow this convention. You need team buy-in before being able to start using this kind of notation so that any devs encountering it understand that this has meaning and isn’t simply some commented out/redundant code.

So yeah, just an idea I’m toying with in order to quasi-qualify some selectors that are intended for use on a specific element but without altering that selector’s specificity.

By Harry Roberts on Monday, July 16th, 2012 in Web Development. Tags: , , , | 7 Comments »


7 Responses to ‘Quasi-qualified CSS selectors’

  1. Jeremy Worboys said on 16 July, 2012 at 11:09 pm

    I’ve found that your final solution (commenting specificity inline) works very well in practice. This is the method I have used in my code for months now and haven’t come across any issues yet. That said, however, I very rarely find myself working in team environments.

  2. Kaiser said on 16 July, 2012 at 11:34 pm

    Great idea – guess I’ll adopt it.

  3. Matt Hinchliffe said on 17 July, 2012 at 4:26 pm

    I’ve personally found writing Zen-Coding formulas to be a nice way of documenting how classes should be used:


  4. Rafał Krupiński said on 17 July, 2012 at 6:29 pm

    I’m wondering if the reason why we can’t do this in SASS:

    .foo {
    color: red;


    is discouraging us from using qualified selectors :)

  5. Rafał Krupiński said on 17 July, 2012 at 6:31 pm

    I meant putting SASS parent (ampersand) selector right behind the “span”.

  6. Guy Routledge said on 18 July, 2012 at 8:49 am

    I tend to go with a bit of commented example markup of how a selector (or module) could be used as sometimes a class ends up being used in more places than perhaps first intended. Eg:

    /* error message for use in form validation eg: */
    /* */
    /* */

    .error {
    /* color, background, border styles etc. */

  7. Matty said on 30 August, 2012 at 12:55 pm

    Would the convention of an extra asterisk in the comment, eg “/** element **/” , help identify the code is meaningful? Somewhat like the “$Main” section convention used in your post http://prdesign-studio.co.uk/2012/04/my-html-css-coding-style/

Leave a Reply

Respond to Quasi-qualified CSS selectors

Hi there, I am Harry Roberts. I am a 21 year old web developer from the UK. I Tweet and write about web standards, typography, best practices and everything in between. You should browse and search my archives and follow me on Twitter, 7,791 people do.

via Ad Packs