4 ms·

a) Granted. But we're talking about a specificity after compiling to CSS of: section.myawesomesection { h2{..} } to section.myawesomesection h2 {..}. Definitel

by 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...
    - gotchange 11y ago
      HTML & CSS are like Siamese twins, you can't separate the one from the other and there will always be coupling between them no matter what and the solution you suggested is not optimal in my opinion as I said earlier that what you'd manage to achieve with this is just to shift the burden from CSS to HTML and to turn the organizational/hierarchical problem in CSS to a greater and unpleasant naming one in HTML that I personally try to avoid as much as possible
      - paulojreis 11y ago

by thebouv 11y ago

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...
  - gotchange 11y ago
    HTML & CSS are like Siamese twins, you can't separate the one from the other and there will always be coupling between them no matter what and the solution you suggested is not optimal in my opinion as I said earlier that what you'd manage to achieve with this is just to shift the burden from CSS to HTML and to turn the organizational/hierarchical problem in CSS to a greater and unpleasant naming one in HTML that I personally try to avoid as much as possible
    - paulojreis 11y ago