4 ms·

Nesting is by far the biggest driver for me. I can do vanilla CSS in my sleep, but it's such a cognitive drag.

gitgud 8y ago
I feel that yes SASS requires less source code, but the nesting is kind of an anti-pattern and encourages complex hierarchies of styles which are hard to follow and maintain.
- rhizome 8y ago
  How come I haven't experienced these downsides?
  - andykx 8y ago
    I'm with you. My SCSS is really just CSS with nesting. My CSS is cleaner without any downside. I've never experienced issues with maintainability, even in large CSS files.
  - pixelbash 8y ago
    That's where I am on this. Before nesting I had to take great care to avoid conflicts. I guess this is what BEM set out to solve, but it seems to have limitations.
    - BigJono 8y ago
      Why would sass have any effect on whether or not you have conflicts? You can just do things in plain CSS with descendant (' ') selectors, same as if they were nested in sass.
      - mercer 8y ago
        Sure, but that's a bit like arguing that you don't need 'scope' for your variables and you can just prepend the function name (or multiple nested function names). Or that you don't need modules but can just put all your code in one file. At the very least support of nesting is a huge convenience, but in practice I've also found that it saves me from all sorts mistakes, whether it's because I'm being stupid, or refactoring things. That said, overusing nested selectors can be a problem too. I generally try to limit myself to two levels of nesting (component -> element), and then a third for pseudo-classes (:hover, :selected, etc.) and pseudo-elements (:before, etc.).
  - gitgud 8y ago
    Probably for the same reason some people don't see the downsides of C++ or Java... you tend not to see the downsides, if you're good at it. I just feel that nesting (which Sass encourages) leads to complexity and fragility.
- type0 8y ago
  As with everything, don't overdo it and you'll be fine.
- GordonS 8y ago
  I generally stick to only 1 level of nesting - I still find that really beneficial.
- stickfigure 8y ago
  Hi, you seem to be the leading critic of nesting on this page, so I have a question for you. Assuming you're using a component framework like React, Vue, or Angular (and not a shadow dom based system like Polymer), how do you isolate your component CSS? When I make a component 'MyComponent', I give it the className 'MyComponent'. Then I can create a SCSS file and scope its entire contents: .MyComponent { // all the css specific to MyComponent } Without nesting, how do you keep your component-specific CSS from polluting the rest of your app? Do you scope every rule every time? Isn't that tedious?
  - gitgud 8y ago
    Thank you, I'll wear the title of: leading critic of nesting proudly! disclaimer I'm not a hugely experienced programmer, but have done a few open source projects in Vue, React and am currently working on a series of Angular applications with a team at work. In Vue and Angular component styles are automatically encapsulated at the component level by scoping (I think) so nesting isn't really necessary to target specific components. Angular also recently deprecated a method of breaking out of component styling and soon it will be completely removed from the framework. Although I'm a critic I'm not totally against nesting, I just feel that SASS encourages it, so without discipline things can get very complex and fragile. One level of nesting is OK with me though I suppose...
    - rhizome 8y ago
      without discipline things can get very complex and fragile In what way(s) is SASS different than anything else in this regard?
      - gitgud 8y ago
        True, this could be said for any system, but in this case SASS makes it easy to create nested relationships, whereas CSS makes it hard.
  - riz_ 8y ago
    Not OP, but you could use CSS modules, styled components or styled-jsx, all of which auto-generate unique classnames (styled-jsx uses a HTML attribute for it, I think).
namelosw 8y ago
Nesting is bad, because moving any element would break your style. And there's also performance impact. I found scoped css like component or BEM just make sense, which only encourage you nest one level in block namespace.
- psychometry 8y ago
  There's no performance impact. Styles are precompiled locally before deployment.
  - namelosw 8y ago
    There is, at runtime browser needs to do extra matching. https://stackoverflow.com/questions/13829959/nested-selectors-performance-impact-and-less https://stackoverflow.com/questions/13829959/nested-selector... It's about Less but the same rule applies to CSS and Sass.
    - steveax 8y ago
      Note the date on that. It’s my understanding that with modern browsers, except in pathological cases, selector performance is pretty much a non issue.
- dmitriid 8y ago
  BEM is just an awkward workaround for the lack of nesting. You’re manually creating nesting hierarchies and naming them (something a computer should be doing). And yes, the moment you move something, everything breaks. Because instead of moving/renaming just the parent selector you have to move/rename all the related child selectors.
  - namelosw 8y ago
    No what I mean by move something I mean adjust HTML structure, and deeply nested stylesheet means less flexible code. You can move anything within a BEM block without breaking style, instead of couple the CSS and HTML structure, which doubles every change. And BEM is a workaround of names pace, not nesting. Nesting is not what CSS lack of. Instead what CSS really lack for is basic abstraction like function (same as function component in react to HTML). Given CSS is basically similar to key value pair (data), a first class function model would solve most of the problems - reusing, encapsulation, abstraction etc.
jorgesborges 8y ago
Nesting is only an asset with thoughtful consistency. There are so many different ways to organize a stylesheet with nesting it can easily become unruly. But I like it now because I've found a method that works for me while also cleaning up my html. In some cases I can preclude the necessity of having to declare class names. section { h1 {}, p {}, img {}, } In other cases I have an index with easy-to-find classes. .hero { .gradient {}, .description {}, .signup {}, } EDIT: I meant to reply to a different comment but oh well.
sureaboutthis 8y ago
> vanilla CSS Is there another kind of CSS?
- rhizome 8y ago
  You know what I mean, Sheldon.
  - sureaboutthis 8y ago
    My point is, one need not apply an adjective to something that does not need qualifying. Just like "vanilla" JavaScript. You are either using JavaScript or you're not but people have been doing that for years and now I see posts asking for definitions or differences between "vanilla" and other flavors of js. Terminology is important but I see it's not important among some people and other hobbyists online.
    - goddtriffin 8y ago
      I can't speak for the others, but when I use the terms 'vanilla JavaScript' and 'vanilla CSS', the distinction I'm trying to make is that I'm not using any libraries or frameworks. There is a meme within the community about 'vanilla JavaScript' called VanillaJS: http://vanilla-js.com/ http://vanilla-js.com/ https://stackoverflow.com/questions/20435653/what-is-vanillajs https://stackoverflow.com/questions/20435653/what-is-vanilla...
      - sureaboutthis 8y ago
        Saying I'm using JavaScript is sufficient. Or stating "I'm not using any libraries or frameworks" works, too.
        mercer 8y ago
        This is a weird thing to argue about. The overwhelming majority of front-end projects and developers that I encounter use some kind of library, framework, or compilation/build tool. It's common enough to basically be the default. If you use 'plain' or 'vanilla' javascript (or CSS), you're doing something less common, at the very least around these parts, and so qualifying this makes sense. The mere fact that many people clearly seem to feel a need to point this out makes it so. Why would they otherwise? Judging by your comment history, the vast majority of your contributions here boil down to some kind of dig at how 'people these days' are 'doing it wrong', and how obviously you are superior to that and how you don't see the need for any of this new-fangled stuff. I'm honestly curious whether that's just role-playing, or if that kind of superiority about being older and wiser is somehow important to you. I'd very much prefer it if you shared the wisdom you've accrued in a more constructive way, because as far as I can tell you're not actually wrong about a lot of this stuff. Older and wiser curmudgeons have played a valuable role in my development, but your approach strikes me as self-serving and somewhat poisonous to the/any community. But of course you're free to do as you please.

I feel that yes SASS requires less source code, but the nesting is kind of an anti-pattern and encourages complex hierarchies of styles which are hard to follow and maintain.

rhizome 8y ago
How come I haven't experienced these downsides?
- andykx 8y ago
  I'm with you. My SCSS is really just CSS with nesting. My CSS is cleaner without any downside. I've never experienced issues with maintainability, even in large CSS files.
- pixelbash 8y ago
  That's where I am on this. Before nesting I had to take great care to avoid conflicts. I guess this is what BEM set out to solve, but it seems to have limitations.
  - BigJono 8y ago
    Why would sass have any effect on whether or not you have conflicts? You can just do things in plain CSS with descendant (' ') selectors, same as if they were nested in sass.
    - mercer 8y ago
      Sure, but that's a bit like arguing that you don't need 'scope' for your variables and you can just prepend the function name (or multiple nested function names). Or that you don't need modules but can just put all your code in one file. At the very least support of nesting is a huge convenience, but in practice I've also found that it saves me from all sorts mistakes, whether it's because I'm being stupid, or refactoring things. That said, overusing nested selectors can be a problem too. I generally try to limit myself to two levels of nesting (component -> element), and then a third for pseudo-classes (:hover, :selected, etc.) and pseudo-elements (:before, etc.).
- gitgud 8y ago
  Probably for the same reason some people don't see the downsides of C++ or Java... you tend not to see the downsides, if you're good at it. I just feel that nesting (which Sass encourages) leads to complexity and fragility.
type0 8y ago
As with everything, don't overdo it and you'll be fine.
GordonS 8y ago
I generally stick to only 1 level of nesting - I still find that really beneficial.
stickfigure 8y ago
Hi, you seem to be the leading critic of nesting on this page, so I have a question for you. Assuming you're using a component framework like React, Vue, or Angular (and not a shadow dom based system like Polymer), how do you isolate your component CSS? When I make a component 'MyComponent', I give it the className 'MyComponent'. Then I can create a SCSS file and scope its entire contents: .MyComponent { // all the css specific to MyComponent } Without nesting, how do you keep your component-specific CSS from polluting the rest of your app? Do you scope every rule every time? Isn't that tedious?
- gitgud 8y ago
  Thank you, I'll wear the title of: leading critic of nesting proudly! disclaimer I'm not a hugely experienced programmer, but have done a few open source projects in Vue, React and am currently working on a series of Angular applications with a team at work. In Vue and Angular component styles are automatically encapsulated at the component level by scoping (I think) so nesting isn't really necessary to target specific components. Angular also recently deprecated a method of breaking out of component styling and soon it will be completely removed from the framework. Although I'm a critic I'm not totally against nesting, I just feel that SASS encourages it, so without discipline things can get very complex and fragile. One level of nesting is OK with me though I suppose...
  - rhizome 8y ago
    without discipline things can get very complex and fragile In what way(s) is SASS different than anything else in this regard?
    - gitgud 8y ago
      True, this could be said for any system, but in this case SASS makes it easy to create nested relationships, whereas CSS makes it hard.
- riz_ 8y ago
  Not OP, but you could use CSS modules, styled components or styled-jsx, all of which auto-generate unique classnames (styled-jsx uses a HTML attribute for it, I think).

namelosw 8y ago

Nesting is bad, because moving any element would break your style. And there's also performance impact. I found scoped css like component or BEM just make sense, which only encourage you nest one level in block namespace.

psychometry 8y ago
There's no performance impact. Styles are precompiled locally before deployment.
- namelosw 8y ago
  There is, at runtime browser needs to do extra matching. https://stackoverflow.com/questions/13829959/nested-selectors-performance-impact-and-less https://stackoverflow.com/questions/13829959/nested-selector... It's about Less but the same rule applies to CSS and Sass.
  - steveax 8y ago
    Note the date on that. It’s my understanding that with modern browsers, except in pathological cases, selector performance is pretty much a non issue.
dmitriid 8y ago
BEM is just an awkward workaround for the lack of nesting. You’re manually creating nesting hierarchies and naming them (something a computer should be doing). And yes, the moment you move something, everything breaks. Because instead of moving/renaming just the parent selector you have to move/rename all the related child selectors.
- namelosw 8y ago
  No what I mean by move something I mean adjust HTML structure, and deeply nested stylesheet means less flexible code. You can move anything within a BEM block without breaking style, instead of couple the CSS and HTML structure, which doubles every change. And BEM is a workaround of names pace, not nesting. Nesting is not what CSS lack of. Instead what CSS really lack for is basic abstraction like function (same as function component in react to HTML). Given CSS is basically similar to key value pair (data), a first class function model would solve most of the problems - reusing, encapsulation, abstraction etc.

jorgesborges 8y ago

Nesting is only an asset with thoughtful consistency. There are so many different ways to organize a stylesheet with nesting it can easily become unruly. But I like it now because I've found a method that works for me while also cleaning up my html. In some cases I can preclude the necessity of having to declare class names. section { h1 {}, p {}, img {}, } In other cases I have an index with easy-to-find classes. .hero { .gradient {}, .description {}, .signup {}, } EDIT: I meant to reply to a different comment but oh well.

sureaboutthis 8y ago

> vanilla CSS Is there another kind of CSS?

rhizome 8y ago
You know what I mean, Sheldon.
- sureaboutthis 8y ago
  My point is, one need not apply an adjective to something that does not need qualifying. Just like "vanilla" JavaScript. You are either using JavaScript or you're not but people have been doing that for years and now I see posts asking for definitions or differences between "vanilla" and other flavors of js. Terminology is important but I see it's not important among some people and other hobbyists online.
  - goddtriffin 8y ago
    I can't speak for the others, but when I use the terms 'vanilla JavaScript' and 'vanilla CSS', the distinction I'm trying to make is that I'm not using any libraries or frameworks. There is a meme within the community about 'vanilla JavaScript' called VanillaJS: http://vanilla-js.com/ http://vanilla-js.com/ https://stackoverflow.com/questions/20435653/what-is-vanillajs https://stackoverflow.com/questions/20435653/what-is-vanilla...
    - sureaboutthis 8y ago
      Saying I'm using JavaScript is sufficient. Or stating "I'm not using any libraries or frameworks" works, too.
      - mercer 8y ago
        This is a weird thing to argue about. The overwhelming majority of front-end projects and developers that I encounter use some kind of library, framework, or compilation/build tool. It's common enough to basically be the default. If you use 'plain' or 'vanilla' javascript (or CSS), you're doing something less common, at the very least around these parts, and so qualifying this makes sense. The mere fact that many people clearly seem to feel a need to point this out makes it so. Why would they otherwise? Judging by your comment history, the vast majority of your contributions here boil down to some kind of dig at how 'people these days' are 'doing it wrong', and how obviously you are superior to that and how you don't see the need for any of this new-fangled stuff. I'm honestly curious whether that's just role-playing, or if that kind of superiority about being older and wiser is somehow important to you. I'd very much prefer it if you shared the wisdom you've accrued in a more constructive way, because as far as I can tell you're not actually wrong about a lot of this stuff. Older and wiser curmudgeons have played a valuable role in my development, but your approach strikes me as self-serving and somewhat poisonous to the/any community. But of course you're free to do as you please.