Hacker News Reader

Comment by rhizome | Hacker News Reader

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

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.

How come I haven't experienced these downsides?

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.

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.

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.

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.).

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.

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?

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...

without discipline things can get very complex and fragile

In what way(s) is SASS different than anything else in this regard?

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.

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).

I see.

These solutions all seem quite a lot more complicated than nested scopes! And at least for styled components (angular, I presume) and styled-jsx (react), they're framework-specific. Why are these solutions better?

As with everything, don't overdo it and you'll be fine.

I generally stick to only 1 level of nesting - I still find that really beneficial.

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.

> vanilla CSS

Is there another kind of CSS?

You know what I mean, Sheldon.

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.

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/

https://stackoverflow.com/questions/20435653/what-is-vanilla...

Saying I'm using JavaScript is sufficient. Or stating "I'm not using any libraries or frameworks" works, too.

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 don't care if you didn't need it, because it's helpful for clarity regardless.

https://stackoverflow.com/a/40115909/135845

Unfortunately, I see that "The Ubuntu Web Team" decided to shit the bed and steal the name for the CSS framework they created. So fsck me I guess.

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.

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.

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.

There's no performance impact. Styles are precompiled locally before deployment.

There is, at runtime browser needs to do extra matching.

https://stackoverflow.com/questions/13829959/nested-selector...

It's about Less but the same rule applies to CSS and Sass.

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.

When we are talking about nesting we are not talking about generating `.page #left-section .box .button {}`... This would be bad. Nesting used properly is something like `.myWidget .button, .myWidget .title, .myWidget .main-section {}`. You can then move .myWidget anywhere you want and the styles would follow.

Reply on news.ycombinator.com