Hmmm... yes and no. It is ok to do things like that, but classes really should be named to show what is common about the data within them. If there isn't anything common between two tags then there is every chance that the requirement of the classes will diverge later.
Example requirement: all navigation items will be white on blue all comment descriptions will be white on blue
- all navigation items will be white on blue, helvetica with a margin of 1px
- all comment descriptions will be white on blue, arial with a margin of 4px and a padding of 2px
Is it better to give them both a class of whiteonblue where
.whiteandbluewhiteonblue {
font-color: white;
background-color: blue;
}
or to have repeated code
.navitems {
font-color: white;
background-color: blue;
// more css
}
.commentdesc {
font-color: white;
background-color: blue;
// more css
}
I argue the latter. There is no connection between navitems and commentdescs and thus the likelihood is that when one changes, the other will not. Do you really want to have to search through the html for the right class, remove the class, add a new one (whiteonred) before going to the CSS at that point? I don't.
Likewise Javascript. Maybe you want the same thing onclick in the initial design but the likelihood is that if one changes, the other one will not. It's easy enough to say
$(".navitems, .commentdesc")
If you stick to this policy, I suspect you'll find that your question goes away pretty quickly, but where it doesn't then what you're doing is fine.