Welcome to CSS Wizardry—Web standards design and development


Tags in CSS files

7th August, 2012 in Web Development

When working with large (and particularly OO) CSS your chunks of code in a stylesheet(s) are less likely to be separated by type, but rather by function. That is to say, you might have objects that both deal with images but live nowhere near each other in the stylesheet.

N.B. please refer to this gist before/whilst reading this article.

For as long as I can remember I’ve always placed a dollar sign before any section titles in my CSS; this is so that I can find a section quickly (and limit my search scope to sections only) simply by running a find for $[SECTION NAME].

This is all well and good when I know what section I’m after, but what if I want to find any section that handles images, or perhaps I need to know what CSS is available forex for use on lists? I need a way of searching within sections, not just their titles. Enter CSS tags

If you take a look at the example CSS you should see that with each section title I have a list of tags. The media object’s tags are ^images ^text ^layout ^structure, the sprite object carries the tags ^images ^icons. If I want to find any objects that pertain to certain types of component then my search now is simply ^[tag name].

By prepending the tags with another character (I chose the caret as it isn’t a frequently occuring glyph in CSS) I can limit my search scope to just tags.

So now if I want to style up some image content I know all I need to do is a find for ^images and I can see exactly what objects I already have at my disposal. If nothing appropriate exists I create a new component or object and give that a tag of ^images for the next dev to find!

As with my recent quasi-qualified selectors tip, this is only really of any use of the whole team buys into it, but I think it could be super useful and is something I’m hoping to implement soon.

By Harry Roberts in Web Development. Tags: , , , | 16 Comments »


Video: Breaking Good Habits—Front-Trends, 2012

19th July, 2012 in Speaking

Here is the video from my talk Breaking Good Habits which I gave in April of this year at Front-Trends in Warsaw, Poland. My voice sounds unusually deep and you can see my boxer shorts for the first 25 minutes but it seems okay; I was absolutely terrified but I’m pleased my nerves didn’t show through too much!

On Vimeo: https://vimeo.com/44773888

My Front-Trends writeup.

By Harry Roberts in Speaking. Tags: , , | 9 Comments »


Shoot to kill; CSS selector intent

17th July, 2012 in Web Development

One type of CSS in particular makes me cringe every time I see it; poor selector intent. Poor selector intent means carpet bombed selectors whose key selector has way too broad a reach; a selector like .header ul{} as opposed to one like .main-nav{}, .widget h2{} instead of .widget-title, article > p:first-child{} as opposed to .intro{}. Selectors whose intent isn’t specific enough.

It’s worth noting that selector intent is something I completely made up at some point today; if you think there’s a better name then please let me know!

Let’s take a closer look at the .header ul{} example. Let’s imagine that ul is indeed the main navigation for our website. It lives in the header, as you might expect, and is currently the only ul in there; .header ul{} is fine, right? Not really. I mean sure, it might work, but it’s not very good. It’s not very future proof and certainly not explicit enough. As soon as we add another ul to that header it will adopt the styling of our main nav and the the chances are we won’t want it to. This means we either have to refactor a lot of code or undo a lot of styling on subsequent uls in that .header to remove the effects of the far reaching selector.

Your selector’s intent must match that of your reason for styling something; ask yourself ‘am I selecting this because it’s a ul inside of .header or because it is my site’s main nav?’. The answer to this question will determine your selector.

It’s all about the key selector…

What determines the impact of a selector is its key selector. The key selector is a very important thing in the world of CSS as browsers read selectors right to left. This means the key selector is the last one before the opening {, for example:

.header ul      { /* ‘ul’ is the key selector */ }
.ul li a        { /* ‘a’ is the key selector */ }
p:last-child    { /* ‘:last-child’ is the key selector */ }

As I discuss in Writing efficient CSS selectors, the key selector plays a big part in CSS efficiency, so it’s worth bearing that in mind, but where selector intent is concerned this is basically the place you need to be looking to see how far reaching your selector is. html > body > section.content > article span{} is a ridiculously convoluted and terrible selector that no one anywhere would ever write (right?) but despite how specific and disastrously over the top it is, its key selector (span) is still very, very broad. It doesn’t matter so much what comes before your key selector, it’s only the key that really matters.

As a general rule you should try and avoid any key selector that is a type selector (basically an element, like ul or span or whatever) or a base object (e.g. .nav or .media). Just because something is the only .media object in your content area it doesn’t mean it always will be.

Let’s keep looking at the .header ul{} example. Let’s assume our markup is thus, as we’re using the nav abstraction:

<div class=header>

    <ul class=nav>
        [links]
    </ul>

</div>

We could select this in one of several ways:

.header ul{
    [main nav styles]
}

This is bad because as soon as we add any other ul to our header it will look like our main nav. This is dangerous but thankfully easily avoidable.

Secondly we could use:

.header .nav{
    [main nav styles]
}

This is marginally better than the .header ul example, but barely so. We can now safely add another ul without risk, but we can’t add anything else with a .nav class; that means adding sub-navs or breadcrumbs will be a nightmare!

Finally, our best solution would be to add a second class to the ul; a class of .main-nav:

<div class=header>

    <ul class="nav main-nav">
        [links]
    </ul>

</div>

.main-nav{
    [main nav styles]
}

This is good selector intent; we are selecting this element now for exactly the right reasons, not coincidental/circumstantial ones. Now we can add as many more uls and .navs to that .header and the scope of our main nav styles will never reach anything else. We’re no longer carpet bombing!

Keep your key selector as explicit and specific as you possibly can, preferring for it to be a class over anything else. Applying specific styling through a vague selector is dangerous. A generic selector should always carry generic styling and if you want to target something in particular you should perhaps add a class to it. Specific intent requires a specific selector.

Real-life example

A really good example of where I messed up on this myself is on a project I did at Sky; I had a selector which was simply #content table{}. (Eww, I even used an ID!!!) This is a troublesome selector for three reasons; firstly it uses an ID which is a big no, secondly it has a lot higher specificity than it needs to and lastly—and most importantly—it has a poor selector intent. I wasn’t wanting to style these tables because they were in #content, that was just how the DOM landed so that’s how I chose to target them. Entirely my bad.

For the first few weeks this was fine but then all of a sudden we needed to add some tables inside #content that didn’t want to look anything like the previous ones. Uh oh. My previous selector was far too far reaching, I was now having to undo a blanket style I’d set on every table in the #content div. If I’d had a better selector intent then instead of:

#content table{
    [foo styles]
}
#content .bar{
    [undoing foo styles]
    [bar styles]
}

I should/would have had:

.foo{
    [foo styles]
}
.bar{
    [bar styles]
}

And a lot less headaches. By thinking ahead and having a lot more considered selector intent then I would have had a much easier time…

Exceptions

Of course there are always exceptions. It’s perfectly reasonable to have selectors like .main-nav > li where your key selector is a type selector. It also makes perfect sense to target every a inside something like this:

html{
    color:#333;
    background-color:#fff;
}

/* Inverted colour scheme for promotional items. */
.promo{
    color:#fff;
    background-color:#333;
}
    .promo a{
        color:#fff;
        text-decoration:underline;
    }

That is a reasonably sensible far-reaching selector where it does make sense to style every a in a pretty carpet bombed manner.

Final word

In general, instead of carpet bombing your elements, shoot to kill; target them specifically and explicitly. Make sure your selector intent is accurate and targeted.

Think more carefully about why you want to target something and pick a more explicit and sensible selector; refine your selector intent. Do you mean:

.header em{}

or do you really mean:

.tagline{}

Do you want:

.footer p{}

or do you really want:

.copyright{}

Is it wise to select:

.sidebar form{}

or would a safer bet be:

.search-form{}

Consider your CSS selectors’ intent; are you being specific enough? Are your selectors matching things for the right reasons, or is it just happy circumstance? Shoot to kill. Be a CSS sniper, not a CSS carpet bomber.

Incidentally, opting to switch out a longer selector like .header ul for something like .main-nav will also help reduce specificity and increase selector efficiency; win-win-win!

It is also worth noting that Jonathan Snook wrote something similar called the depth of applicability

By Harry Roberts in Web Development. Tags: , , , | 26 Comments »


Quasi-qualified CSS selectors

16th July, 2012 in Web Development

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.

Continue reading this post →

By Harry Roberts in Web Development. Tags: , , , | 7 Comments »


The open/closed principle applied to CSS

21st June, 2012 in Web Development

A question that often gets asked of OOCSS is ‘What happens when an object changes?’. That is to say, if you have a basic object that underpins a dozen different components, what happens when changing that object will favourably impact one component, but negatively impact the other 11? With so much abstracted and shared CSS, simple changes to a base object can have massive ramifications across whole projects; how do you deal with that?

Well, the short answer is never change your base abstractions.

Continue reading this post →

By Harry Roberts in Web Development. Tags: , , , | 20 Comments »


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