5 ms·

I have to disagree with the first two points and concur with the last two. Modularity can be achieved in CSS with ease (with Sass or any other capable preproce

I have to disagree with the first two points and concur with the last two. Modularity can be achieved in CSS with ease (with Sass or any other capable preprocessor) and I do it all the time and I haven't come across a problem like he cited in his prose. The extended «@import» keyword/statement handles this perfectly and you can do wonders with it, you just have to keep a mental record of the hierarchy in your head (You already do that with the order of <link> and <style> elements as well as the CSS individual rules within a single file) and aim for well encapsulated components that are as loosely coupled as possible to the surroundings in the markup and you will have a true piece of mind. As with nesting, yeah this could be a source of annoyance and inconvenience but I usually set a ceiling of 3 levels deep maximum for any component with rare exceptions when the need arises but most of the time I don't exceed the 3 level nesting limit and the codebase is still very very manageable.

emn13 11y ago
The issue with nesting rules like "max three" is that you really don't want 3 levels of nesting, you want zero. Setting an arbitrary cap isn't a bad coping mechanism, but you might end up with pervasive low-level nesting, even though you almost certainly don't need it. In almost all cases I see, when people nest with SASS (or less), they don't really mean "in this context, this item is styled like this", what they mean is "this item only ever exists in this context". And if you use nesting for that, then you have at least one of three problems: - it might be entirely redundant - as in you get exactly the same style if you just omit the surrounding selector blocks. This is quite common if you're using classes heavily. - it might be a "clever" way to avoid using a class name. This is terrible idea; it's not clever to call something `.frugal > div > span > span > b`, not even via nesting, it's simply undescriptive. Give the beast a name already, and use that. If you're after this style, why not use inline style tags? (No seriously - that's not as terrible as it sounds). - You've got too many catch-all selectors, and are fighting a selector specificity battle. Nesting here is again a really, really terrible solution, because you've just made the problem that much worse. Nobody is ever going to understand why the components layout breaks when they refactor if and one layer is added or removed. If your style depends delicately on these kinds of interactions, you're in a world of pain. Use @import, and consider refactoring your usage of general or catch-all selectors. I think its good advice to avoid nesting, especially more than one level of nesting. It's never necessary (just use compound selectors instead), and where compound selectors turn into a tedious, repetitive mess you've got techdebt you should be resolving, not making worse. Avoid doesn't mean "never use" - but if your css has even one instance of three-level deep nesting, I feel confident in suggesting that you're making things fancier than they need to be. Nobody likes that programmer that left behind his "clever" solution to save a few dozen keystrokes once, but that needs lots of context to understand, and that's exactly what nesting in SASS is.
- MatekCopatek 11y ago
  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.

emn13 11y ago

The issue with nesting rules like "max three" is that you really don't want 3 levels of nesting, you want zero. Setting an arbitrary cap isn't a bad coping mechanism, but you might end up with pervasive low-level nesting, even though you almost certainly don't need it. In almost all cases I see, when people nest with SASS (or less), they don't really mean "in this context, this item is styled like this", what they mean is "this item only ever exists in this context". And if you use nesting for that, then you have at least one of three problems: - it might be entirely redundant - as in you get exactly the same style if you just omit the surrounding selector blocks. This is quite common if you're using classes heavily. - it might be a "clever" way to avoid using a class name. This is terrible idea; it's not clever to call something `.frugal > div > span > span > b`, not even via nesting, it's simply undescriptive. Give the beast a name already, and use that. If you're after this style, why not use inline style tags? (No seriously - that's not as terrible as it sounds). - You've got too many catch-all selectors, and are fighting a selector specificity battle. Nesting here is again a really, really terrible solution, because you've just made the problem that much worse. Nobody is ever going to understand why the components layout breaks when they refactor if and one layer is added or removed. If your style depends delicately on these kinds of interactions, you're in a world of pain. Use @import, and consider refactoring your usage of general or catch-all selectors. I think its good advice to avoid nesting, especially more than one level of nesting. It's never necessary (just use compound selectors instead), and where compound selectors turn into a tedious, repetitive mess you've got techdebt you should be resolving, not making worse. Avoid doesn't mean "never use" - but if your css has even one instance of three-level deep nesting, I feel confident in suggesting that you're making things fancier than they need to be. Nobody likes that programmer that left behind his "clever" solution to save a few dozen keystrokes once, but that needs lots of context to understand, and that's exactly what nesting in SASS is.

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