4 ms·
I've worked on a project which used a technique like this, but was not even as closely mirroring the DOM, and the end result was terrible. We ended up with spec
by config_yml 15y ago
I've worked on a project which used a technique like this, but was not even as closely mirroring the DOM, and the end result was terrible. We ended up with specificity horrors which will best not be seen. Nobody wants to touch those stylesheets anymore.
- joevandyk 15y agodid you use child selectors? did you use @extend?
- kylemathews 15y agoSome details would be nice.
- config_yml 15y agoWell, multiple editors were at work. The approach described creates selectors that were generally more specific than they needed to be. Eventually, people needed something to be styled differently in a context that was already heavily specified. So they needed to have even more specific selectors to override an existing selector. As soon as someone stuck some ID in front of that whole selector (which is almost too easy using SASS/SCSS) it was basically game over. I think OOCSS is an approach to help here, but once you have such a mess it is pretty hard to refactor.
- rimantas 15y agoGod, when this OOCSS thing will be forgoten. It just moves mess to another place and instead of mess in CSS you get mess in CSS and HTML.
- config_yml 15y agoI guess you can create a mess either way. For me OOCSS was easy to scale out onto lots of elements and it was certainly easier to keep track of what is affecting what once you change something.
- kuroir 15y agoI wrote a little post response to the OP article showing the problems and what you should do to avoid them. [CSS: Don’t take control of the Cascade, make love to it.](http://kuroir.com/post/10148994785/css-dont-take-control-of-the-cascade-make-love-to http://kuroir.com/post/10148994785/css-dont-take-control-of-...) Hope you find it interesting.