Hacker News Reader

Comment by necolas | Hacker News Reader

I haven't had the experience that HTML is harder to maintain if you use classes more liberally. What this approaches forces you to do is: write or edit CSS every time you want a new combination of existing traits...which isn't ideal either.

The post also suggests that certain class names are "unsemantic", when they obviously aren't. They just have different meaning to the sorts of class names the author is advocating.

View on HN

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.

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

Reply on news.ycombinator.com