2 ms·

Not exactly, it's something I've been noticing from my experience with CSS and many teams with many members which were experienced programmers but without any C

Not exactly, it's something I've been noticing from my experience with CSS and many teams with many members which were experienced programmers but without any CSS experience. I've shared these ones with my team, however: http://philipwalton.com/articles/css-architecture/ http://philipwalton.com/articles/css-architecture/ http://philipwalton.com/articles/side-effects-in-css/ http://philipwalton.com/articles/side-effects-in-css/ http://philipwalton.com/articles/extending-styles/ http://philipwalton.com/articles/extending-styles/ http://benfrain.com/the-ten-commandments-of-sane-style-sheets/ http://benfrain.com/the-ten-commandments-of-sane-style-sheet... P.S. A good heuristic I'd like to point out (and hard-code in any CSS newbie's brain) 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. Very, very few exceptions to this. Structure (HTML) is a different concern than styling (CSS) and it might change frequently; it should have minimal impact on styling. P.P.S. Another good notion is that CSS is truly like Tetris. Errors do pile up. If you are over-specific when defining a selector, soon you'll have to do a even-more-specific one to override it. If you are too confident and define a leaky rule (e.g. all `<p>` elements inside a given widget), soon you'll have to create code to override it.

gotchange 11y ago
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.

gotchange 11y ago

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.