To all the “Use efficient CSS selectors” optimisation gurus: Get a grip and concentrate your development time on areas that get good performance improvements. Does changing selectors actually make a noticable difference in page load? Are you pre-optimising code to get a negligible speedup? Does IE process selectors right to left? I would be loath to lose the advantages of tidy code for a change if it only gives an insignificant performance improvement.

The only relevant selector performance testing I have found so far is: http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/ (and even that is not for a realistic page).

I agree. Of course, you wouldn’t want to write duplicate selectors. It’s not only bad for performance but also for code maintainability. In the example you described, I would abstract those rules out into a more general (more shallowly nested) selector.

Just to be clear, I’m not suggesting you deeply nest everything just for the sake of doing it. General rules — list-styles, basic typography, page structure — should not use deep selectors.

The main benefit here is that you can quickly determine the specificity of a set of rules by glancing at the selector (i.e. shorter selectors indicate more general rules whereas longer selectors indicate more specific rules.)

In other words, if you deeply nest things unnecessarily, it not only makes for bad code but also destroys the benefit of using the method in the first place.

for example, what if you need another class that has the exact same styling as

#our_team .employee { width: 230px; height: 65px; float: left; }

but inside of another parent id called “#their_team ?”

do you create another whole nested classes for “#their_team?”

Yes. Most browsers do render deeply nested selectors more slowly. The reason is simple enough. Time is wasted reading through superfluous selectors before getting to the last few relevant selectors. But how much does this matter?

Well, it depends on your preference. I really like the flexibility and modularity that comes with deep nesting, and I’m willing to trade a small amount of performance for those gains. But if you’re a geek for optimization, on the other hand, then this method is probably not for you.

That said, I think developers should be careful about optimizing performance to absurd extremes. There are plenty of other factors that go into writing good code – stability, clarity, flexibility, etc. And often these other factors come only at the price of speed.

For example, would you write a web application in C? Of course not. You’d use a higher level language, like Java or Ruby. No one cares that C is about four times faster than Ruby or Java. We’re happy to trade performance for the many benefits of developing in a higher level language.

It’s simplistic to think about speed as the ultimate measure of good code. It’s much better to think of it like a currency. Speed is useful because we can choose to trade it for other gains – tightened security, new features, usability, etc.

I wonder what you think of indenting your css file? it help a lot for readability.

I think that if a class exists and it’s used only once within a containing div, just use the containing div and and that class.

Also a good example is for lists. Instead of doing this:

ul li a { styles... }

It’s better to do this:

ul a { styles... }


That is, if only one link type exists in that list. Otherwise use classes, and use the same technique.

It does, without a doubt, lend more to readability and maintainability than development with only shallow css. Despite Sara W’s comments, a 500 ms gain in rendering time, for example, does not usually win out over the time and cost of development with poorly structured and/or poorly organized css.

I demand excellent organization in all facets of development from my developers, and the combination of shallow + deep nesting is a fantastic technique.