4 ms·

Do you have a resource for the last point you mentioned?

paulojreis 11y ago
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.
nmjohn 11y ago
If you're looking to improve the CSS you end up writing - I highly suggest considering BEM [0]. It stands for block, element, modifier and defines a fairly rigid structure to build components with. tl;dr: It promotes extremely simple, component based/modular css that is _trivial_ to refactor with confidence unexpected regressions won't pop up. I'm primarily a backend engineer, but I do full-stack work, especially in my free time, and after seeing it used by our front-end devs at work I decided to try it on my own project - and for the first time ever, I felt like the CSS I was writing actually made logical sense in the same way any program I'd write makes logical sense. Adding constraints is majorly helpful when your language has hundreds of virtually equivalent ways (or at least seemingly equivalent) of doing the same thing - it's just setting yourself up for confusion later. With or without any sort of preprocessor, BEM is still crazy beneficial if you have a codebase with many people touching the styles, it - a.) promotes good css practices by limiting the usage of entirely un-necessary slow css selectors because they'd require convention to be broken (and then caught easily in a code review) b.) promotes extremely DRY components c.) defines a very simple yet specific way of handling style variations that make DRY component variants (eg a button component could have a red, green or blue modifier) obvious to everyone on the team in a way almost analogous to a primitive in a programming language -- most codebases don't otherwise have a defined pattern for this leading a lot of wheel reinvention and extra complexity which in turns breeds more complexity, leading to truly disgusting css. Of course there are downsides, by putting limits on a language some things will necessarily become more difficult/complex to accomplish, but I personally find the benefits far outweigh this. Additionally, I'm not sure how it works trying to integrate it into a mature codebase - I could see that being a challenge for some projects/CSS code styles, but I've not done that so can't speak from more than speculation. [0]: https://css-tricks.com/bem-101/ https://css-tricks.com/bem-101/

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.

nmjohn 11y ago

If you're looking to improve the CSS you end up writing - I highly suggest considering BEM [0]. It stands for block, element, modifier and defines a fairly rigid structure to build components with. tl;dr: It promotes extremely simple, component based/modular css that is _trivial_ to refactor with confidence unexpected regressions won't pop up. I'm primarily a backend engineer, but I do full-stack work, especially in my free time, and after seeing it used by our front-end devs at work I decided to try it on my own project - and for the first time ever, I felt like the CSS I was writing actually made logical sense in the same way any program I'd write makes logical sense. Adding constraints is majorly helpful when your language has hundreds of virtually equivalent ways (or at least seemingly equivalent) of doing the same thing - it's just setting yourself up for confusion later. With or without any sort of preprocessor, BEM is still crazy beneficial if you have a codebase with many people touching the styles, it - a.) promotes good css practices by limiting the usage of entirely un-necessary slow css selectors because they'd require convention to be broken (and then caught easily in a code review) b.) promotes extremely DRY components c.) defines a very simple yet specific way of handling style variations that make DRY component variants (eg a button component could have a red, green or blue modifier) obvious to everyone on the team in a way almost analogous to a primitive in a programming language -- most codebases don't otherwise have a defined pattern for this leading a lot of wheel reinvention and extra complexity which in turns breeds more complexity, leading to truly disgusting css. Of course there are downsides, by putting limits on a language some things will necessarily become more difficult/complex to accomplish, but I personally find the benefits far outweigh this. Additionally, I'm not sure how it works trying to integrate it into a mature codebase - I could see that being a challenge for some projects/CSS code styles, but I've not done that so can't speak from more than speculation. [0]: https://css-tricks.com/bem-101/ https://css-tricks.com/bem-101/