CSS rule naming

I am trying to set some standard guidelines for myself when working with CSS.

I’ve always been in doubt what’s best, if any, to use in such a situation.

Let’s say I have a sidebar containing a number of links.

Now should the styles for these links be given a rule like this:




Right now I would opt for the first as it seems a bit cleaner and also allows me to neatly group all styles that are
particular to the sidebar in one place.

Which one would you recommend, or maybe a completely different style of naming?

You can chain anything you want :).

I do agree it’s not well documented. I googled to find the correct spelling although after a few queries I was unable to find anything of use (it kept bringing up “concentrating” ;))

Juist do whatever naming scheme works for you :). There is no “convention” unless you start naming stuff like .red or something like that.

Don’t make the class name what it will actually aesthetically look like.

It’s as simple as that. Do what works for you :slight_smile:

I would do something like this:

#sidebar-links { unique styles go here; }
#sidebar-links li { unique styles go here; }
#sidebar-links a { unique styles go here; }
<ul id="sidebar-links">
  <li>Links go here</li>
  <li>Links go here</li>
  <li>Links go here</li>

Watch out for the first one, as the browser might think you are targeting an element with an ID of sidebar and a class of links. Not sure if that’s actually valid CSS, but better not to use dots in names.

It’s valid CSS. It’s called concentating :).

I hope I spelled it right lol ;). IE6 is a bit quirky with that though so it’s best to avoid it.

ConCATenating—from “catena”, a chain (Latin). I just haven’t found a clear statement in any book that you can chain a class to an id, although I’ve seen it done. Must check the docs, I suppose.

I would do as kgraves.sd suggested, and try to target HTML elements as much as possible e.g.

#sidebarLinks li {}

This minimises the number of class and id attributes required in the markup.

As far as the way I name my selectors, I favour camel casing e.g.

#sidebarLinks {}

I have a very pragmatic reason for choosing this approach. When trying to select a string in my IDE by double-clicking it, only the portion between hyphens will be selected. If there are hyphens in the selector name, this is very frustrating!

For example, if I double clicked within “links” in “sidebar-links”, only the word “links” would be selected, rather than the entire string. In my experience most text editors behave the same way.

Whereas if my selector name is camel cased, a double click will select the whole thing.

Regarding concatenation, if IE6 support is important to you be aware that IE6 has problems with chained selectors:

I just haven’t found a clear statement in any book that you can chain a class to an id, although I’ve seen it done. Must check the docs, I suppose.

Yes as Ryan said #id.classname or .classname.classname is fine but Ie6 is buggy with it and best avoided if ie6 support is needed.

Yes but with camel case there is much much more room for error since you have to make sure the subsequent words are capitalized otherwise the selector won’t work.

Since you will be repeating rules in the CSS camel case can bring significant headaches if you mess one up, and they are extremely hard to notice in the CSS :wink:

Juist do whatever naming scheme works for you . There is no “convention” unless you start naming stuff like .red or something like that.

There is a convention: make the name logically explain it’s function, not it’s effect, for example call a list of links… linkList but don’t call it redBorder :wink:

PS: I prefer camel case because using non alphanumeric characters in CSS names kinda make me nervous. :stuck_out_tongue:

Personally I’ve not found this to be an issue (ok, maybe once or twice!), as I’m very used to camel casing from PHP and ActionScript.

But I agree it does introduce a margin for error.

For me it comes down to the convenience of being able to easily select the class/id name in my text editor, for copy/paste purposes. I weighed up the pros and cons of various naming conventions, and decided that for me the advantages of camel casing outweighed the negatives.

Another approach that would have met my requirements (double-clicking selects the entire class/id name), and eliminated any margin for error is if I used only lowercase, e.g.

#sidebarlinks {}

In fact I used to name selectors in this manner, but found them confusing to read. After that I switched to hypenated selector names, but the double-click thing constantly tripped me up, so I eventually settled on camel case. Somewhere in between I might have used underscores too!

I guess there is no perfect approach. Unless my IDE has a hidden preference to ignore hypens when making a selection… :smiley:

EDIT: I had been lead to believe that underscores were illegal in CSS selectors, as stated by Roger Johansson: “Class and id names can only consist of the characters [A-Za-z0-9] and hyphen (-)”). http://www.456bereastreet.com/lab/developing_with_web_standards/css/

However, reading the W3C section on CSS2 Syntax (http://www.w3.org/TR/CSS2/syndata.html#characters) it in fact states that underscores are acceptable.

Does anyone have thoughts on this?

If the W3C says their acceptable, their acceptable. While 456 Berea St is a pretty well respected blog (especially when it comes to accessibility), they probably just forgot that underscores were still valid. I think Camel Case only becomes an issue if you forget case-sensitivity is an issue in coding. :slight_smile:

If in my example I would want to move the links from the sidebar to another section of the page, it would make more sense to have the ul having a class of .links instead of .sidebar-links which would result in some confusion as it would not still be located in the sidebar.

if i was using .links and then having a #sidebar.links rule I would just create a new rule #newsection.links in the css.

Underscores are allowed in css2.1 but not previously in css2.

The changes section at the w3c lists the differences between the specifications.

Aha! Thanks for the info. It’s good to know that underscores now have the stamp of approval.