Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Question: what are the practical considerations for the syntax in class and id values?

Note that I'm not asking about the semantics, i.e. the actual words that are being used, as for example described in this blogpost. There are a lot of resources on that side of naming conventions already, in fact obscuring my search for practical information on the various syntactical bits: casing, use of interpunction (specifically the - dash), specific characters to use or avoid, etc.

To sum up the reasons I'm asking this question:

  • The naming restrictions on id and class don't naturally lead to any conventions
  • The abundance of resources on the semantic side of naming conventions obscure searches on the syntactic considerations
  • I couldn't find any authorative source on this
  • There wasn't any question on SE Programmers yet on this topic :)

Some of the conventions I've considered using:

  1. UpperCamelCase, mainly as a cross-over habit from server side coding
  2. lowerCamelCase, for consistency with JavaScript naming conventions
  3. css-style-classes, which is consistent with naming of css properties (but can be annoying when Ctrl+Shift+ArrowKey selection of text)
  4. with_under_scores, which I personally haven't seen used much
  5. alllowercase, simple to remember but can be hard to read for longer names
  6. UPPERCASEFTW, as a great way to annoy your fellow programmers (perhaps combined with option 4 for readability)

And probably I've left out some important options or combinations as well. So: what considerations are there for naming conventions, and to which convention do they lead?

share|improve this question
    
CamelCaseEverythingInCode –  Ryathal Mar 28 '12 at 19:59
7  
BUT_WHY_WOULD_YOU_DO_THAT_IS_THE_QUESTION? ;) –  Jeroen Mar 28 '12 at 20:00
    
I usually lowercase classes and CamelCase everything else. No particular reason –  Antarr Byrd Mar 28 '12 at 20:12
    
"css-style-classes, which is consistent with naming of css properties (but can be annoying when Ctrl+Shift+ArrowKey selection of text)" - is only an issue if you use a sub-optimal text editor ;-) –  tdammers Mar 29 '12 at 6:09
    
@Ryathal that is PascalCase (or UpperCamelCase), camelCase (or lowerCamelCase) looks like thisExample. –  Danny Varod Apr 3 '12 at 10:48
add comment

closed as not constructive by Walter, ChrisF Aug 2 '12 at 17:05

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

7 Answers

up vote 16 down vote accepted
+100

Bounty or not, to some extent the choice will always be a "matter of preference" - after all, how would you feel if the W3C recommended (or even imposed) a certain convention that you didn't feel was right?

Having said that, though, I personally prefer the lowerCamelCase convention, and I'll give the reasons and practical considerations I've used to make up my mind - I'll do so by a process of elimination, using the numbering from your question:

(5.) justnoteasilyreadablebecauseyoudontknowwherewordsstartandend.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING.

(4.) historical_incompatibility_plus_see: Mozilla Dev Documentation.

(3.) a-bit-trickier-to-explain... as you mention, selectability in text editors is one issue (as with underscores, depending on the editor), but for me it's also the fact that it reminds me of the syntax reserved for vendor-specific keywords, even if those start with a hyphen as well as having words separated by them.

So this leaves your (1.) and (2.), UpperCamelCase and lowerCamelCase, respectively. Despite the mental link to Java classes (which are, by a more clearly defined convention, UpperCamelCase), CSS class names seem, to me, to be better off starting with a lowercase letter. Perhaps that is because of XHTML element and attribute names, but I guess you could also make the case that having CSS classes use UpperCamelCase would help to set them apart. If you need another reason, lowerCamelCase is what the W3C uses in examples for good class names (though the URL itself, annoyingly, disagrees with me).

I would advise against (4.), (5.) and (6.), for the reasons stated above, but suppose that arguments could be made for either of the other three.

Whether or not you (or anyone else for that matter) agree with me on this matter is up to you though. The fact that you haven't got a definite answer quoting authoritative sources by now can be taken as a hint that there isn't such a thing as a definite standard on this issue (else we'd all be using it). I'm not sure that's necessarily a bad thing.

share|improve this answer
    
Thanks! You mention (like most other answers) that it's a matter of preference, but also complement it with some practical advice, and a few good links on the more important considerations (such as the one_on_icompatability). Even though I still consider going with the suggestion in @tdammers' answer (naming-with-dashes), the answer given here is the one that actually answers the question I asked. So: bounty + accepted, plus many thanks :) –  Jeroen Apr 3 '12 at 20:09
    
Many thanks back - as long as you stay consistent, I think any of those three is fine. There's not much between them, and if you look at sites across the net, I'm sure you'll find plenty of examples of each ;-) –  Amos M. Carpenter Apr 4 '12 at 1:47
    
+1 Though, I'm sure it's necessarily a bad thing. While I'm all for community driven standards efforts on naming, formatting, and general style conventions, the lack of uniformity can make project inheritance a nightmare (not to say that such a nightmare would be alleviated by standards, they'd probably not be followed) The fact that CSS, feeble and declarative, is so intermingled with client and server side application logic even as simple hooks, it yearns for unified structure (by it yearns, I mean I yearn) –  Dan Lugg Feb 7 '13 at 1:55
    
I definitely agree that underscores should be avoided (except perhaps for ID names if your server-side code uses underscores). Hyphens can't be used as a separator in programming languages because the hyphen is also the minus operator. But in any other context where you might use underscores, I think hyphens are a more natural choice - easier to type and for URLs, more visible when a URL is underlined. –  Matt Browne Nov 15 '13 at 12:13
add comment

Words in CSS class names should be separated with dashes (class-name), as that's how words in CSS properties and pseudo-classes are separated and their syntax is defined by the CSS specs.

Words in ID names also should be separated with dashes, to match the syntactic style of class names and becaus ID names are often used in URLs and the dash is the original and most common word separator in URLs.

share|improve this answer
    
Ah +1, I like the mention of id's in URL's. Although the funny bit is, to do some poking around on this, I went to check how Wikipedia does this. For example the Browswer support section of the Wikipedia CSS article gave: <span id="Browser_support" class="mw-headline">Browser support</span> :O –  Jeroen Apr 3 '12 at 20:17
add comment

It's mostly a matter of preference; there is no established standard, let alone an authoritative source, on the matter. Use whatever you feel most comfortable with; just be consistent.

Personally, I use css-style-with-dashes, but I try to avoid multi-word class names and use multiple classes wherever possible (so button important default rather than button-important-default). From my experience, this also seems to be the most popular choice among high-quality web sites and frameworks.

Lowercase with dashes is also easier to type than the other options (excluding the hard-to-read nowordseparatorswhatsoever convention), at least on US keyboards, because it doesn't require using the Shift key.

For id's, there is the additional practical consideration that if you want to reference elements by their ID directly in javascript (e.g. document.forms[0].btn_ok), dashes won't work so well - but then, if you're using jQuery, you're probably going to use them through $() anyway, so then you can just have $('#btn-ok'), which makes this point mostly moot.

For the record, another convention I come across regularly uses Hungarian warts in ID's to indicate the element type, especially for form controls - so you'd have #lblUsername, #tbUsername, #valUsername for the username label, input, and validator.

share|improve this answer
    
Thanks for the answer! I'm gonna put a bounty up though, hoping someone has an answer that makes this less a "matter of preference". If none show up though I'll be sure to accept your answer. –  Jeroen Apr 2 '12 at 18:23
add comment

I strongly believe the thing that matters most is consistency.

There are two ways to look at this:

  1. A good argument can be made for alllowercase or css-style-clauses (probably the better choice) because they will be the most consistent with the code they'll be in. It will lend a more natural flow to the code overall and nothing will be jarring or out of place.

  2. An equally good argument can be made for a style that is distinct from HTML tag names or CSS clauses, if it will differentiate IDs and classes in a way that aids readability. For example, if you used UpperCamelCase for IDs and classes, and didn't use it for any other construct or purpose, you would know you had hit on one every time you saw a token in that format. One restriction this might impose is that it would be most effective if every ID or class were a 2+ word name, but that's reasonable in many cases.

In writing this answer out I came to find that I'm much more inclined toward the second choice, but I will leave both because I think both cases have merit.

share|improve this answer
add comment

It's all a matter of preference really, or matter of laziness. CamelCasing is easier to type, but I prefer to use underscore notation as I find it personally easier to read and debug than CamelCase. There is no one set coding convention to abide by, I've never worked at a place that had the same coding guidelines as the place before it.

Most companies have guidelines you generally have to abide by any way to keep the code clean and easier for everyone to work on. If you're a freelancer, then you can go all out as you're the only person working on the code. There are only 2 coding conventions in my opinion to follow: CamelCase or Underscore notation. My advice is to pick one and then stick with it.

share|improve this answer
add comment

You can use names with hyphens for class and camel case or with underscore for id.
Eg:

class="my-class" id="myId"  
class="my-ui-class" id="my_id"
share|improve this answer
    
Mind to add some comments down voters ;) lol. –  kadaj 8 hours ago
add comment

You seem oblivious to one simple fact: most CSS is not done by programmers.

It's done by graphic designers.

They don't care about our editing wars and couldn't care less about what we do with the shift key.
They don't even probably know where that fancy _ key is. (or what its name is)

They don't care about code aesthetics, they care about aesthetic aesthetics.

(And they may have a point there)

They don't read the spec, they get the tutorial.
And then double-check references on w3schools.

Some of them probably believe they cannot use uppercase classnames because of reasons.
They're full of weird, mostly irrelevant misconceptions.

share|improve this answer
2  
I guess that depends where you work, I've worked with designers that are fairly militant about standards; By the sounds of things you're used to working with inexperienced front-end developers, or print designers masquerading as web designers. Plus, I do a reasonable amount of CSS on my projects, as do a fair few of my peers at work, I think the design/programming split really depends on the company dynamics. –  Ed Woodcock Apr 3 '12 at 10:31
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.