Classes Vs. IDs And Descendent Selectors [Audio]

Posted: 13 Dec 2012 05:30 AM PST

Umm…ahh…you know…well I survived my first audio post well enough to put together a second one, though I did have a acase of the…umms…this time around. In between the…ahhs…I talk about a discussion I caught a couple of weeks ago on the role of ids and descendent selectors in css.

If for some reason you don’t see the audio above click here. Below is a summary of what’s included in the audio.

The discussion played out over several articles and podcasts across a few different sites.

Chris refers to the following post in the podcast with Jeffrey. It’s when he stopped using ids and moved entirely to classes.

A Line In The Sand, A Story About Meaty Chili and Using Classes

It began innocently enough on Smashing Magazine. Chris Coyier does a semi-regular Q&A post there and in response to a question about how to recognize bad css code he mentioned using css selectors that are too specific and as example offered the following awful selector.

1	.article #comments ul > li > a.button

Harry Roberts expanded on the answer over at CSS Wizardry with a number of really good suggestions of what not to do. Toward the end of his post he mentioned selectors and said never to use ids in css. Use them for html fragment identifiers and javascript hooks, but never for css styling hooks. Among his reasons were

You can also abstract what’s in an ID to reusable and modular classes
Ids are too specific (255 times more than classes) and lead to specificity issues

Jeffrey Zeldman then joined the discussion. Harry’s comment to never use ids in css didn’t sit well with him. Jeffrey doesn’t have anything against using classes, but felt the advice to never use ids was too dogmatic. He said that properly used ids with descendent selectors can be a good thing. They can be more semantic and lead to less code than adding classes everywhere.

As luck would have it, both Harry and Jeffrey were back to back guests on the weekly ShopTalk show hosted by Chris and Dave Rupert and each expanded a little more on their thoughts abut classes, ids, and descendent selectors.

My Thoughts

This topic is something I think about a lot or at least have for the last year or so. If you remember last spring I wrote a few posts about css practices and looked at object oriented css and smacss among other things.

I’d be lying if I said those posts led to me completely changing practices. For the most part I still write css much the way I used to, though the ideas behind oocss and smacss resonated with me. Both seek to further separate content, structure, and presentation. Pushing for more modular code and design makes sense to me.

For years my practice has been to look at part of the design and start writing css to make my html look like the design. Typically that meant adding an id to a higher level structure in the design and working down to more specific elements through descendent selectors. For example if there’s a list I want to style in a sidebar, I’d add id=”sidebar” to the main div and work my way down

1  2  3

#sidebar ul { }  #sidebar li { }  etc.

That leads to a couple of problems, though.

Stylistic patterns that are repeated inside high level elements need to be coded more than once. The above styles lists in the sidebar, but not lists in footer.
Because of the above I’d typically look at all the lists in a design and style the default list the way the majority would look. That leads to having to overwrite styles on all the other lists.

DRY (Don’t Repeat Yourself) CSS is one way to solve the first problem. Better use of classes another way.

Styles are set on the class and the class can be added to both the lists in the sidebar and those in the footer. The two lists will display the same and the css is in one place and easily reused again. There’s also no overwriting since only lists with the class applied get the styles.

None of this is hard to understand, but what has been more difficult for me is the change in thought process.

It’s still instinct for me to reach for an id, though I am getting better at reaching for classes. What’s more difficult to change is how I go about styling things. I still see an element in the design and begin to write css to make it look how I want. Instead I should be looking for abstract patterns across elements and write css for those in classes.

Something Chris mentioned in one of the podcasts (The one with Jeffrey I think) made things clearer for me. It wasn’t anything profound, but rather a dose of obviousness that I supposed I needed to hear.

find a pattern and give that pattern a class

With that in mind I think the way for me to change my thought process is to go on coding like I have been when initially setting up styles, but as soon as possible begin refactoring my css. As soon as I see a pattern across elements, I should think about moving that pattern to a class.

On a larger scale I’ll save many of these classes in a library that can be reused across projects. I think in time a couple of things will happen.

I’ll build up a library of reusable classes that I’ll reach for more often.
I’ll naturally begin writing css with abstract patterns and classes instead of adding styles to more concrete design objects.

If ids still find their way in, that’s ok. I have nothing against using them.

How do you approach ids and classes? Do you prefer one over the other? Is it something worth thinking about?

The post Classes Vs. IDs And Descendent Selectors [Audio] appeared first on Vanseo Design.