Well, just re-reading some of the current bookmarks in my bag. To note:
- Tantek’s 8 steps to serving better (X)HTML, and
- Rundle’s My 5 CSS Tips, step #5 specifically.
I am trying to clean up and make things more efficient here at work. One goal would be to have a base CSS that will serve as a starting point for our Producers and Frontend peeps. Another goal would probably be a convention on how to use it and/or create new classes and IDs.
One of the things that keeps coming up lately would be the naming convention of classes and IDs. I used to implement this kind of format “class_name”. Then, only to switch to “class-name” in early ’06. Fast-forward to a couple of months into the year during a project, I came to find out that if you are referring to either a classname or an ID (i.e. getElementById, or something like that) that the value’s hyphen get stripped out. Can someone confirm this phenomena and/or myth? That is, for example, doing “id-name” would be implemented like so:
document.getElementById("idname")
With that however, would it be more readable using a camelCased name? Although against Tantek’s step #4 in terms of saving the user(s) potential headaches. But would there be problems if there was a standard within one’s organization? That is, classes and IDs written as a variable, i.e. somethingLikeThis; no hyphens and no underscore.
I look forward to hearing your endless wisdom on this subject sirs and madams. Thanks in advance.
The O’Reilly book JavaScript & DHTML Cookbook indicates that the DOM strips out hyphens in CSS ID’s and replaces them with camelCase, but this no longer appears to be the case. I am not able to reproduce that effect anyway, but that book is from 2003 and this post is from 2006, so my guess is times (and technology) have changed.
Thanks for the input Anselm. Like you said, time and tech have changed. Currently, I use hyphens but I use this convention when naming IDs for my forms:
#formName
I recall running into a problem with DOM and forms ID-names specifically a while back. I HTH. Have a good one.
It’s an interesting legacy behavior though, and could explain where the hyphenated CSS selectors convention came from (I might note that Adobe Flex still does this with CSS). I was doing some searching on a solid reason for using hyphens, but was not able to find anything conclusive, which surprised me since it really does seem like the predominant format.
The only vague reason (aside from the past behavior of being stripped out by the DOM) I could find for hyphenation over other formats is that hyphenation follows the format of CSS attributes (font-size, text-decoration, etc.).
Others have said they use a underscore instead because “-” has another meaning in the scripting world, that of the subtraction operator.
In a certain respect camelCase would actually make the most sense, because it would make it consistent with other programming paradigms. The classes and ID’s on an HTML page could be thought of as object instances, which by convention are written in camelCase in other languages. But this is stretching CSS beyond what it actually is.
The underscore and hyphen are more readable, which is important, but an annoyance I find with them is that many text editors see each part of a hyphenated word as a separate part, so when you double-click on the name (say to copy and paste it elsewhere) the whole name does not get selected. This happens more so with hyphens than with underscores from my experience.
And then I’ve also seen underscore_Separated_Camel_Case, yikes!
“underscore_Separated_Camel_Case” haha–scary.
Yah, I agree with you with regards to the use of camelCasing in development (backend). Meanwhile, interesting insight which makes sense with regards to the use of hyphens being tied to style rules. In regards to text editors, thank God for TextMate and Notepad++ =)