[ianstormtaylor]

Right, I addressed that in the post. They are "non-semantic" as far as people normally apply the word "semantic" to HTML. You might say that they are still semantic, fine. But you'd be hard pressed to argue that they are different than classes like `.dropdown` or `.menu`, and that difference makes them _much_ more susceptible to change. Which means if you're littering your markup with those classes, you will have to sync those changes all over the place.

Yes there are still changes to make (there always will be), but with the OOSass approach you're doing it in a single place. Want all of your statuses to be `.media` modules? One place. Not n places. Moving the work from the n-side to the 1-side is the mark of a good abstraction.

[pault]

I've been working on my own framework for the last several months and I've been back and forth a bit on this issue. On the one hand I strongly believe that 1.) writing and editing markup is easier than writing CSS (browser inconstancies, context switching), and 2.) your coworkers are probably a lot more proficient with HTML than CSS. On the other, when you start getting class attributes like "col-12 secondary-panel rounded-top inner-shadow pam" you may have gone off the rails a bit. I guess it depends on where you want the mess to be. One argument that keeps me coming back to the multiple class names camp is that keeping your classes semantic and extending your patterns requires writing more Sass every time you add new content, where going nuts with class names doesn't. I love being able to add a new component to the app without having to open up a single stylesheet. We also have trouble running into the 4095 selector limit in IE8 when we package everything, so every extra class we can shave off helps (although in this specific case the problem is more with having a Sass codebase that has been rode over roughshod by five+ developers for the last year).