Hacker News Reader

Comment by dhimes | Hacker News Reader

This looks good. I've been using mdn mostly; but I usually go deep into CSS for a bit then leave it for long periods of time.

That said, what has replaced SASS? I'm struggling to find a preprocessor that allows nesting/grouping etc. Or is that built into CSS by now? Being able to nest CSS was a game changer for me in terms of css organization.

View on HN

Nesting is not possible in vanilla CSS. However, there is an Editor's Draft about it which has gained some momentum recently.

https://linkedlist.ch/ref/25/

Nesting is still not possible in regular CSS. In fact, it's the only reason I still use Sass—I don't use any of Sass's other advanced features.

The function stuff is pretty sweet. EDIT: By that I mean "mixins"

I'd say that "nesting is bad" has replaced SASS. Nesting encourages long selector chains which are generally a bad practice. That CSS makes this painful is a nice reminder to only use long selector chains where necessary.

I see. That just goes against the way I naturally think, unfortunately— which is why I thought SASS was such a great breakthrough. I do understand it, though, because when I want to modify something in some over-written hunk of garbage CSS it is a real pain to try to get the selector that actually works (thank god for dev tools).

One of the challenges with CSS is that it has so many ways to do the same thing, and it needs that because there are so many different workflows.

If you are in an environment where you have 0 control over how the HTML is structured I can see where long selectors are helpful, but when you do have full control over the HTML they are a huge anti-pattern.

Agreed, if by "helpful" you mean "painful but necessary because the asshole that wrote it didn't put a unique class on the main target of the div." But nesting doesn't necessarily imply long selectors, if done properly IMHO. If I have full control, I can put a class on the likely-to-be-selected element (ultimate target- the content) that allows me to get to it immediately so that I can, say, change the font.

In other words, I like nested CSS when I have a nested structure on the page. Then each class relates to one thing, and I can maintain continuity of the outer containers (say) as I change the inner ones.

In the old days, we didn't have column inside of content inside of page inside of ..... We just had whatever we had and css nesting wasn't as logically congruent with the structure.

Now, though, we have hugely nested pages (which stinks, but whatever), including a lot of inline-written CSS and the only way to get to it is long selectors. I agree it's an anti-pattern.

But you can have nesting and not require long selectors. And if you do need them for some god-forsaken reason, they are easy to find from a SASS structure.

Sass still has a lot of popularity in the BEM world where you can use nesting to generate flat classnames that would be tedious to write out by hand, e.g.:

  .element {
    &__title {
      color: red;
    }
  
    &__subtitle {
      color: blue;
    }
  }

which compiles down to:

  .element__title {
    color: red;
  }
  
  .element__subtitle {
    color: blue;
  }

There's a lot of (valid) criticism that this makes code harder to grep, although if you structure things well it's still easy to find via the base element class. BEM and approaches like this in general tend to require a lot of discipline and organization to pull off effectively.

This is where I'd step in and argue BEM is a terrible idea. Any time you're encoding hierarchy like this into strings you have failed. BEM is the worst of both worlds since you have higherarchical class names and you have still created CSS that's heavily dependent on the hierarchy.

CSS wants you to write:

.element.title { color: red; } .element.subtitle { color: blue; }

Any technique that depends on discipline and organization has already failed.

I don't think CSS has any particular preference, which is why there's so many different ways to approach these problems. But I do agree, I don't think I've ever worked on a BEM codebase that didn't end up messy, and the disciplined approach almost always means making tons of small naming/organization decisions as you code, which is tiring and difficult to maintain.

People scoff at CSS-in-JS and atomic approaches like Tailwind (although Tailwind seems to get a lot of support around these parts now!), but I've really come to see the value in side-stepping these issues entirely.

CSS does have a preference.

CSS has absolutely 0 knowledge of your BEM hierarchy, they're just different names as far as its concerned. The developer has just chosen to pretend that a hierarchy exists where there is none.

CSS cannot do trees, but it can do logical AND and OR, so you can somewhat express a hierarchy as a union of the different levels of your tree, so

.button.login.green has a logical meaning in CSS where .button__login--green is no different than using .pinapple as a class name.

Fair enough, I think it's safe to say that CSS has a skew towards the cascade and I guess I misunderstood your original meaning there.

Reply on news.ycombinator.com