A simple, but effective, convention in web development is to have different names for css classes based on their use — one for when the class is going to define style and another for when the class is going to be used as a hook for javascript and testing.
There are plenty of articles that talk about how you should name your css, what the files should be called, etc. (Here are some at Snook.ca, Smashing Magazine, and phpied, for example.) The topic has been covered and for the most part is agreed upon.
JavaScript is the same. It’s easy to find articles that talk about what classes should be called, code styles, how to indent. etc. There are not, however, a lot of people who discuss connecting JS to the dom.
We’ve found CSS classes used to connect JS to the DOM are best kept separate from css classes intended for visual style and layout. We preface classes intended for JavaScript with “app-“.
Having this preface allows us to easily indentify the intent of a CSS class. It also allows us to safely remove unused css classes when doing a redesign, eliminating the worry that the removal of a class will have unintended consequences.
This pattern also scales well when writing integration tests. Generally integration tests would look for a specific piece of text or dom element on the page to assert that things have loaded correctly. This becomes an issue when content is updated or the dom is rearraged. Using app- classes allows for your tests to function independently of the content or dom structure. Our tests, instead of calling click_on("Save"), can use click_css(".app-save"), allowing us to update the text “Save” to say “Apply” or “Save All” or even “SAVE.”
Overall this approach has saved us time and headaches as a project grows — allowing us to focus our efforts on testing or visual design and removing the worry that we’ll have cross contamination.