<div class="tab iTab">; with your CSS attached to “.tab” and your JS attached to “.iTab”.
Coincidentally this is something I started doing a few projects ago, thinking separation good / overloading bad, and I have to say I’m completely sold on it, here’s a few specific positive effects I’ve experienced:
Design / Markup changes shouldn’t break JS
If you want to style a list you might put a class on the
ul, if you want those items to be interactive you might target links within the list like so:
$(".listClass a")… Then the design or content changes and it no longer makes sense to have a list, you change it, and the JS falls apart.
CSS classes might not be best put on the interactive element
Imagine in the situation above you want the items on the list to be individually addressable by JS – so you need classes on each item. Do you then use those classes to style the list – even though each item might look the same? No – you put a class on the
ul like before. In other words since the two types of class have different purposes, they should be treated – and named – separately.
It makes collaboration easier
A new front-end dev comes along, sees a CSS class with no styles applied, removes it for the sake of tidiness, JS stops working. Or, a new JS dev comes along, wants to update how the JS works, moves / renames the trigger class, layout falls apart. And for “new dev” you can also substitute yourself, updating the project 6 months later. 🙂
You did a cool slideshow effect in that old project, and want to use it again, but with different styling – which are the class names you need to port over to the new markup to make it work? Cue hunt through the JS.
This is fair on the surface, but if there are interactive elements there, using CSS classes to trigger, then that cross contamination has already happened. Much better in my book to be honest about it.