3 ms·

is that if you're relying on DOM structure (e.g. styling X if he is a descendant or sibling of Y), then you're doing it wrong. Actually this is the way to do i

is that if you're relying on DOM structure (e.g. styling X if he is a descendant or sibling of Y), then you're doing it wrong. Actually this is the way to do it without going overboard with it. Even UI frameworks like Boostrap or Foundation rely on this convention to style elements on the page. Littering the HTML markup with classes all over the place for the illusion of "loose coupling" between the CSS and HTML is an anti-pattern and counter-productive. You just need to use classes when appropriate and necessary and then rely on the inherent and predictable relations between HTML elements to supply styling information and close the deal.

paulojreis 11y ago
I don't like the Bootstrap approach very much. I'd rather litter the markup with classes and then be able to change their order and location in the DOM without affecting styles than having to do changes both in HTML in CSS files - bear in mind that, with DOM dependency, most style changes would imply you to change or at least check the HTML file. It will also make you end up "plugging" exceptions on top of exceptions - element X looks like A when he's a child of Y, but then it will have to look like B when he's a descendant of Z (something common with a page-level class, for instance). This is way safer and maintainable with BEM-like modifiers. I'd say that waiting for "inherent and predictable relations between DOM elements" is a disaster waiting to happen. Of course, there are exceptions (the table mark-up and table styles might be coupled, I guess), but you should try to avoid it. Take a look at http://philipwalton.com/articles/side-effects-in-css/ http://philipwalton.com/articles/side-effects-in-css/, he has a few good points.