6 ms·

That approach - nesting everything inside section.myawesomesection- would hurt: a) Performance (rule matching gets significantly harder as you nest); b) Maint

That approach - nesting everything inside section.myawesomesection- would hurt: a) Performance (rule matching gets significantly harder as you nest); b) Maintainability (did a change in the mark-up? Then check the CSS to see if it still matches); c) Code reuse (obviously). Using a nomenclature-based solution such as BEM, in the other hand, would avoid all these issues (complex, slow and over-specific selectors; DOM dependence; ease of reuse) while still avoiding style leaks. I'd argue BEM is even better at avoiding leaks: if you change all your global <ul> inside your section.myawesomesection, then it will - eventually, sooner or later - leak to a <ul> which you didn't want to style.

thebouv 11y ago
a) Granted. But we're talking about a specificity after compiling to CSS of: section.myawesomesection { h2{..} } to section.myawesomesection h2 {..}. Definitely not wanting to create nests that are so deep the specificity is insane. Could I have just given a class to the h2? Yep. But performance difference between h2.myclass{..} vs section.awesomesection h2{..}? Worth worrying over? Of course, if there really is a difference, it would add up I suppose over a mega-site. So thanks for the food for thought. I'll have to weigh it versus developer happiness I get from the tidy style rules. b) Well, if the markup changes, that can just as well change your CSS too. At some point, some change in the markup, you're going to reexamine the CSS for it. It's not like you write the perfect CSS and walk away because it will always work with the document and all its iterations. Of course, like you said, maintainability is an issue but it isn't exclusive to SASS or my use of nesting via section.myawesomesection either. c) Styles that are in many places get noted and placed so they can be reused. But that one special snowflake of a rule that applies only to this section of content because my designer wants to especially call it out? The rule can be specific. I'm not creating 200 line section.myawesomesection definitions. Reusable items are resuable. Specific items are specific (most often to overwrite a global style say like font, color, this specific absolutely positioned icon, etc). Generally a dozen lines or so. If longer, just like a function getting too long, and I rethink/rewrite. d) I absolutely 100% will check out BEM. I'm no slave to SASS, nesting, or anything like that. I have no idea about BEM will happily switch if it is better.
- paulojreis 11y ago
  Bear in mind that BEM (CSS-wise) is just a nomenclature. What it addresses is exactly excessive nesting and dependence between mark-up and styling. It roughly means that you imply structure via naming conventions instead of nesting (e.g. if you have a box inside a block, you'd style it via single class such as .my-block__my-box, instead of the traditional nesting approach .my-block .my-box). You can - and should - still use SASS (or other preprocessor) with BEM. Some interesting resources regarding this: 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...
  - gotchange 11y ago
    > you'd style it via single class such as .my-block__my-box, instead of the traditional nesting approach .my-block .my-box) What you basically accomplished here is to transfer the problem of complexity from one domain (CSS) to another (HTML) not solving it. Even if Sass provides a visual way to emulate hierarchy by using the & operator and breaking up the name at the significant points for instance: .myblock &-mybox color: black It would be still a mess on the HTML side and there isn't really an equivalent workaround for it with tools like Jade or others. In the end, if the penalty of using a shallow nesting architecture is to increase the specificity score by 1-2 points, I'm willing to take it in exchange of a more readable and maintainable codebase whether in CSS or HTML domain.
    - paulojreis 11y ago
      > What you basically accomplished here is to transfer the problem of complexity from one domain (CSS) to another (HTML) not solving it. Nop. I'm eventually polluting the mark-up with extra and uglier classes, but that's it. A small price to pay for less coupling - just use a class to bind styles to an element. No need to consider "what if this is a child element of X or a sibling of Y?". > In the end, if the penalty of using a shallow nesting architecture is to increase the specificity score by 1-2 points, It's not. It's style leaking, dependence between different system parts (content structure and styles), performance, less reuse...

thebouv 11y ago

a) Granted. But we're talking about a specificity after compiling to CSS of: section.myawesomesection { h2{..} } to section.myawesomesection h2 {..}. Definitely not wanting to create nests that are so deep the specificity is insane. Could I have just given a class to the h2? Yep. But performance difference between h2.myclass{..} vs section.awesomesection h2{..}? Worth worrying over? Of course, if there really is a difference, it would add up I suppose over a mega-site. So thanks for the food for thought. I'll have to weigh it versus developer happiness I get from the tidy style rules. b) Well, if the markup changes, that can just as well change your CSS too. At some point, some change in the markup, you're going to reexamine the CSS for it. It's not like you write the perfect CSS and walk away because it will always work with the document and all its iterations. Of course, like you said, maintainability is an issue but it isn't exclusive to SASS or my use of nesting via section.myawesomesection either. c) Styles that are in many places get noted and placed so they can be reused. But that one special snowflake of a rule that applies only to this section of content because my designer wants to especially call it out? The rule can be specific. I'm not creating 200 line section.myawesomesection definitions. Reusable items are resuable. Specific items are specific (most often to overwrite a global style say like font, color, this specific absolutely positioned icon, etc). Generally a dozen lines or so. If longer, just like a function getting too long, and I rethink/rewrite. d) I absolutely 100% will check out BEM. I'm no slave to SASS, nesting, or anything like that. I have no idea about BEM will happily switch if it is better.

paulojreis 11y ago
Bear in mind that BEM (CSS-wise) is just a nomenclature. What it addresses is exactly excessive nesting and dependence between mark-up and styling. It roughly means that you imply structure via naming conventions instead of nesting (e.g. if you have a box inside a block, you'd style it via single class such as .my-block__my-box, instead of the traditional nesting approach .my-block .my-box). You can - and should - still use SASS (or other preprocessor) with BEM. Some interesting resources regarding this: 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...
- gotchange 11y ago
  > you'd style it via single class such as .my-block__my-box, instead of the traditional nesting approach .my-block .my-box) What you basically accomplished here is to transfer the problem of complexity from one domain (CSS) to another (HTML) not solving it. Even if Sass provides a visual way to emulate hierarchy by using the & operator and breaking up the name at the significant points for instance: .myblock &-mybox color: black It would be still a mess on the HTML side and there isn't really an equivalent workaround for it with tools like Jade or others. In the end, if the penalty of using a shallow nesting architecture is to increase the specificity score by 1-2 points, I'm willing to take it in exchange of a more readable and maintainable codebase whether in CSS or HTML domain.
  - paulojreis 11y ago
    > What you basically accomplished here is to transfer the problem of complexity from one domain (CSS) to another (HTML) not solving it. Nop. I'm eventually polluting the mark-up with extra and uglier classes, but that's it. A small price to pay for less coupling - just use a class to bind styles to an element. No need to consider "what if this is a child element of X or a sibling of Y?". > In the end, if the penalty of using a shallow nesting architecture is to increase the specificity score by 1-2 points, It's not. It's style leaking, dependence between different system parts (content structure and styles), performance, less reuse...