4 ms·

I find it funny that you suggest compound selectors as an alternative to nesting, since nesting exists primarily to avoid the repetitiveness of compound selecto

I find it funny that you suggest compound selectors as an alternative to nesting, since nesting exists primarily to avoid the repetitiveness of compound selectors. I can agree that it might encourage some people to nest more then if they did it by hand, but in my personal case, I was writing long compound selectors already. The ability to nest only made the styling DRY-er and gave it visual structure. High specificity is definitely an issue that needs to be dealt with, but I'm not sure the best solution is to stop using a feature that possibly encourages it but also brings many other useful things to the table. To end on a constructive note - don't forget you can use nesting to concatenate string names as well. .button { &-big {} } will produce .button-big {}, which means you can do some sort of visual nesting without producing unnecessary specificity.

emn13 11y ago
The issue with nesting to hide compound selectors is that it's papering over a problem, not solving it. Hiding a problem tends to make it worse because it's easy to ignore it, and easy to make it much worse. Compound selectors are necessary for context-dependent styling; and all compound selectors are context dependent. Nesting is equivalent. However, context dependency makes it harder to reason about a layout, makes it harder to refactor, and makes it harder to reuse parts elsewhere. DRY-ness is vastly overrated in all programming languages; what matters is composability. You're not writing a compressor. DRY is simply a means to an end; being DRY helps composability because it means that changes to one part of your program don't necessitate changes to the repetitive parts elsewhere. If you need to extract that commonality - of course, do so! But it's much better if you can delete it outright, and in the case of SASS nesting that's almost always the case. For another perspective: every composition in a selector is essentially a nested if in the "program" that is your styles. Do you really need nested ifs all over the place? If someone changes the html structure a bit, are they going to be surprised by which styles match if they fails to keep the styles side-by-side? If you're nesting styles, your styles are likely extremely tightly coupled with your html structure, and any changes that don't in details dovetail with changes to the styles will cause unpredictable consequences. If you're going to do that, consider something like [radium](http://projects.formidablelabs.com/radium/ http://projects.formidablelabs.com/radium/) - i.e. inline styles. But you're probably best off combining that with conventional styles for all the easy, reusable bits.
- gotchange 11y ago
  > Do you really need nested ifs all over the place? A maximum cyclomatic complexity level of 3 is rather acceptable and also the technique of compounded class names you're pushing for is no different than nested selectors since the same abstract logic operations, namely «if» and «and», are at play too under the hood for both cases > If you're nesting styles, your styles are likely extremely tightly coupled with your html structure. That's the whole point of encapsulation. I prefer to draw the encapsulation line at the component level not the sub-componenent level. It's like an application of the "open/closed principle" where the component is open for the outside world to be manipulated as a single unit but it's closed and obscure from the inside. This achieves in my opinion a greater degree of re-usability and portability. You just import the component where you need it and apply the styles you wish and then the component functions the same no matter where you place it because of the loose coupling with the outside world and the tight coupling and high cohesion inside. However, if you'd like to carry out changes on a sub-component level and there isn't any exposed interface already, for instance through a Sass mixin that would allow you to tweak the inner parts, unfortunately you'd have to know what you're doing whether on CSS or HTML front to make sure you are not breaking anything and getting things done correctly. To summarize, the main point of disagreement between me and you is where each one of us would draw the encapsulation line, I prefer a more "macro" approach while you're in favor of more "micro" and granular control over the building blocks of your software which should work fine for either of us simultaneously.

emn13 11y ago

The issue with nesting to hide compound selectors is that it's papering over a problem, not solving it. Hiding a problem tends to make it worse because it's easy to ignore it, and easy to make it much worse. Compound selectors are necessary for context-dependent styling; and all compound selectors are context dependent. Nesting is equivalent. However, context dependency makes it harder to reason about a layout, makes it harder to refactor, and makes it harder to reuse parts elsewhere. DRY-ness is vastly overrated in all programming languages; what matters is composability. You're not writing a compressor. DRY is simply a means to an end; being DRY helps composability because it means that changes to one part of your program don't necessitate changes to the repetitive parts elsewhere. If you need to extract that commonality - of course, do so! But it's much better if you can delete it outright, and in the case of SASS nesting that's almost always the case. For another perspective: every composition in a selector is essentially a nested if in the "program" that is your styles. Do you really need nested ifs all over the place? If someone changes the html structure a bit, are they going to be surprised by which styles match if they fails to keep the styles side-by-side? If you're nesting styles, your styles are likely extremely tightly coupled with your html structure, and any changes that don't in details dovetail with changes to the styles will cause unpredictable consequences. If you're going to do that, consider something like [radium](http://projects.formidablelabs.com/radium/ http://projects.formidablelabs.com/radium/) - i.e. inline styles. But you're probably best off combining that with conventional styles for all the easy, reusable bits.

gotchange 11y ago
> Do you really need nested ifs all over the place? A maximum cyclomatic complexity level of 3 is rather acceptable and also the technique of compounded class names you're pushing for is no different than nested selectors since the same abstract logic operations, namely «if» and «and», are at play too under the hood for both cases > If you're nesting styles, your styles are likely extremely tightly coupled with your html structure. That's the whole point of encapsulation. I prefer to draw the encapsulation line at the component level not the sub-componenent level. It's like an application of the "open/closed principle" where the component is open for the outside world to be manipulated as a single unit but it's closed and obscure from the inside. This achieves in my opinion a greater degree of re-usability and portability. You just import the component where you need it and apply the styles you wish and then the component functions the same no matter where you place it because of the loose coupling with the outside world and the tight coupling and high cohesion inside. However, if you'd like to carry out changes on a sub-component level and there isn't any exposed interface already, for instance through a Sass mixin that would allow you to tweak the inner parts, unfortunately you'd have to know what you're doing whether on CSS or HTML front to make sure you are not breaking anything and getting things done correctly. To summarize, the main point of disagreement between me and you is where each one of us would draw the encapsulation line, I prefer a more "macro" approach while you're in favor of more "micro" and granular control over the building blocks of your software which should work fine for either of us simultaneously.