These days, the difference between a hyphen and an underscore is quite trivial; it doesn’t really matter what you use. The important thing is to stay consistent in your code.

First, unescaped underscores were actually invalid in the (short-lived) CSS 1 specification, and also in CSS 2; they remained thus until a revision made several years later. (If you look at the original regular expressions and the new ones, you can see where underscores were added; I would probably need to trawl through the mailing lists to find the motivation.)

Second, nowhere in any CSS or HTML specification can I recall underscores being officially used as word separators, nor have I seen them in widely-used extensions to them such as WAI-ARIA. Hyphens, on the other hand, are liberally used—and are actually mandated for class names in Microformats!

URLs often use underscores, with Wikipedia being a prominent example. Hyphens still seem to have an edge, though, perhaps owing to the fact that Google did not recognise underscores word separators (though it did recognise hyphens as such) until some time in 2007. Or so says Matt Cutts, who works at Google.

Now that the spec allows them, and the older browsers that used to choke on underscores are no longer part of anyone’s support profile, we can safely and legitimately use underscores. But, in the context of technologies which almost exclusively use hyphens as word boundaries in every other context, they seem out-of-place.

The only respect in which underscores seem to carry substantive benefits is that your form IDs and names can be the same as whatever variable names or properties you use in your back-end programming language. This is seldom a requirement, although you may have something that does this translation for you automatically; in which case, assuming you are more concerned with speed than minutiae of style, there’s little reason to fight the framework.