0

While this popular question, and it's answers cover a fair bit of ground on the subject, I'm curious about what constitutes a valid class name in the wild (at the time of this writing).

<edit> To expand on this, as it is the core of my concern, are we not at a point in the evolution of user-agent technology and standard support, that certain naming hacks can be abandoned, instead re-purposing them for robustness in common use? Understandably, there will always be edge-cases (someone is probably using NN6, with no intention to stop) but I'm an advocate of making things work as expected (read: as pixel-perfect as possible) in 90% of browsers, expecting that the remainder will have an "acceptable" experience. </edit>

Namely, prefixing (or general use of) underscores (_) and hyphens (-). While the CSS spec goes on to say that with escaping, essentially any character (save for NUL) is valid, validity is only as good as it's corresponding support.

So, in the current browser landscape, what are the "do's" and "do not do's" of CSS class naming? Would it be unwise to use any of the following:

.foo { }         /* for completeness... */
.foo-bar { }     /* hyphenated */
.foo_bar { }     /* underscored */
.foo-bar-baz { } /* multi-hyphenated */
.foo-bar_baz { } /* hyphenated then underscored */
.foo_bar-baz { } /* underscored then hyphenated */
.-foo { }        /* leading hyphen */
.-foo-bar { }    /* leading hyphen and hyphenated */
.-foo_bar { }    /* leading hyphen and underscored */
._foo { }        /* leading underscore */
._foo_bar { }    /* leading underscore and underscored */
._foo-bar { }    /* leading underscore and hyphenated */

While escaping is of course an option, I don't think it's feasible for anything more than a trivial implementation. My concern with underscores and hyphens comes from their prevalence of use, but (seemingly) inconsistent support across browsers; at least historically.

Community
  • 1
  • 1
Dan Lugg
  • 18,516
  • 18
  • 99
  • 168

1 Answers1

1

Generally you should avoid underscores completely, and use hyphens -. Hyphens should be used to signify a new "word". Such as .left-column as opposed to .leftColumn or .left_column. Never start a class name with a hyphen though, there is no reason to.

Out of the choices, the ideal ones are:

.foo { }        
.foo-bar { }

The following is acceptable, but if you need three "words" to describe a class you are being too descriptive

.foo-bar-baz { }

This Google style guide to HTML and CSS may be of some use to you

Important bits:

/* Not recommended: meaningless */
#yee-1901 {}

/* Not recommended: presentational */
.button-green {}
.clear {}

/* Recommended: specific */
#gallery {}
#login {}
.video {}

/* Recommended: generic */
.aux {}
.alt {}

/* Not recommended */
#navigation {}
.atr {}

/* Recommended */
#nav {}
.author {}
Dan Lugg
  • 18,516
  • 18
  • 99
  • 168
Andy
  • 13,875
  • 3
  • 46
  • 76
  • Thanks @Andy; Thanks for the linked resource, quite useful; however your initial recommendation of "*avoid underscores*" is the core of my concern and inquiry: *why*? I've read the old IE hacks, and have seen the CSS spec change, and I'm wondering now, are we not at a point of user-agent evolution where these certain conventions can be abandoned? – Dan Lugg Jan 24 '13 at 15:40
  • @Bracketworks I'm not saying you can't use underscores because it will break your code. It's just the standard that people try to abide by. To allow anyone who comes across your code to understand it and it be in a similar convention to what they are used to – Andy Jan 24 '13 at 16:12
  • Fair enough, but that leads me to ask, if that's a standard, then would you consider patterns like [BEM](http://bem.info/method/definitions/) (*it's prescribed scheme at least*) bad? Anyway, this is sort of a digression from my question; I'm wondering in the current state of the web, are hyphens/underscores used as in my example, going to pose support issues. – Dan Lugg Jan 24 '13 at 16:46
  • @Bracketworks I had a big reply ready but yes lets stay on topic. Underscores and hyphens will generally not cause support issues. If they do, its the developer of whatever plugin your using that is to blame. Feel free to use whatever suits you best :) – Andy Jan 24 '13 at 16:49
  • Thanks :) Feel free to share your big reply; if anyone else jumps in, I'll just wiki this. Anyway; my concern about what suits me best **is** on support. I've been trying to find something such as [caniuse.com](http://caniuse.com/) but with historical information (*beyond the scope of my question even*) that can be cross-referenced against browser statistics to find a robust middle ground of the "90%". Building such an reference myself seems redundant as I'd guess it exists somewhere already. – Dan Lugg Jan 24 '13 at 16:50