Check out the previous comments. There’s been quite a bit of debate about this. There’s definitely more to writing quality code than pure performance. For example, we use high level languages – like Ruby and even PHP – rather than something like C which would be about 4X faster. In doing so, we trade performance for a more flexible, maintainable code base.

Deep nesting is a good idea for these same reasons. You’re trading performance for maintainability. That said, I obviously recommend combining/minifying your assets in production, especially if performance is a pressing concern.

The depth of your selectors is not going to cause a significant difference in your page load. That’s just nonsense. Nest as deeply as you like.

But using @import too much could make a difference since it increases the number of http requests. So, if you’re really looking to optimize, you might want to steer clear of @import altogether.

Overall though, I would suggest using something like LESS or SASS to dynamically compile your stylesheets. This lets you have the best of both worlds: You can deeply nest and modularize using @import while still loading all your stylesheets with a single http request.

But according to your example, when would you use .employee, more then once?

Should’nt that also be an ID as well?

It is just a content container, just like #our_team.

Also, reusing ids can sometimes cause javascript errors.

Generally, do you use id’s for the basic elements (container, nav, content, footer)
Then classes for the placement/style of internal elements? (photos, text, etc)

I understand if you used all id’s you wouldn’t be able to nest your styles the way you did, but is there another reason?

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?”