Nov 19 2013 · Application Design
Below is a bit of code to demonstrate what I’m talking about. As a convention, I apply a “ia-” prefix to my interaction classes.
<a href="#" class="btn-primary ia-begin-testing">Begin Testing</a>
- btn-primary has the CSS rules for styling the anchor as a button
- ia-begin-testing is bound to a JS event that triggers some arbitrary “begin testing” action
If the future, if I want to change the button to a link (remove the btn-primary class), change it to a secondary button (btn-primary to btn-secondary), or change styling in any other way, the Javscript code is unaffected and requires no changes.
In addition, the ia-begin-testing class can also be applied to other elements (another button, a link, an anchor wrapping an image, etc.) and is automatically bound to the same interaction functions, without writing additional JS DOM selection code. The ia-begin-testing class can also be removed, or changed to another interaction class, and the styling on the button remains the same.
While IDs and data attributes are also good choices for architecting this sort of style/interaction separation, I like classes for 2 reasons:
- Selection via class is relatively fast across all browsers compared to selection via data attributes
- Compared to IDs, classes can be re-used allowing the same interactions to be shared by multiple elements (e.g. a button and a link can both trigger the same function)