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.
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.