Hacker News Reader

Comment by clairity | Hacker News Reader

two things that sass has that i want to see in plain ol' css:

1. nesting - but this is coming!

2. mixins - not even static mixins are coming =(

static mixins might seem to be limited in utility at first, but it'd alleviate a lot of duplicate css by allowing you to have orthogonal groups of styles. so you could have sets of static mixins for borders/shadows, spacing, layout, fonts, etc. that you could mix and match into both element and class styles as you need.

too much nesting can lead to a rat's nest of css (ha), but shallow nesting (1 level mostly, 2 levels on occasion) adds clarity and structure.

View on HN

Nesting is basically the only reason I always use sass, even in small projects. Will be happy when that comes to css.

That’s been available for years with PostCSS. You can use a lot of tomorrow’s CSS today with PostCSS Preset Env.

Aren't both sass and postcss supersets of css that require transformation plugins? What am I gaining from switching from sass to postcss here?

Nothing, because also PostCSS is a specific program, while there’s a ton of ways to compile SCSS… Ruby, node-js, built-in compiler in the IDE, GUI frontends, etc.

Posted on another thread and haven’t heard an answer, so I’ll post it here too… Serious question: how do you refactor code when using nesting? In my experience it makes styles impossible to audit.

I tend to use nesting in combination with some form of scoped CSS (e.g. CSS modules, or the built-in forms available in Vue/Svelte). For me, this helps a lot with refactoring code, because each style is only relevant to a single component. Nesting is then useful within that component for handing specific states (e.g. `.active`, or indeed `:active` and other pseudo-classes), but it can never get too out of hand, because the CSS as a whole is very connected to its component. If I change the component markup, I know where to look up change the CSS (and vice versa), and if I'm making broader changes then I know quite easily when a particular file or declaration is no longer necessary.

Mixins could be done, but I believe we'd need some sort of lexically-scoped reference first, so that we're not trying to apply mixins that can dynamically based on style resolution, which is what sunk @apply. See https://github.com/w3c/csswg-drafts/issues/3714

yah, i've read that thread before, as well as tab atkins' "abandoning @apply" post, and i think both are trying to solve problems that are beyond css itself (js-style scoping in the first, and shadow dom styling in the latter).

what i'm imagining is something more like this very contrived example:

  :root {
    --thick: 4px;
    --border-color: black;
  }

  $standard-border {
    border: 2px solid var(--border-color); /* not evaluated here */
  }

  div {
    @apply $standard-border; /* evaluated here */
  }

  /* somewhere else, perhaps a different file */
  .bordered {
    --border-color: grey;
    @apply $standard-border; /* evaluated here */
    border-width: var(--thick); /* an override */
  }

here, the string would simply be substituted into place and then evaluated as if the substitution had been written there all along. this seems like it would avoid the multiple evaluation and circularity issues that have sunken prior proposals.

There was a mixins proposal for `@apply`[0][1] but it was unfortunately dropped

[0]: https://tabatkins.github.io/specs/css-apply-rule/

[1]: https://www.xanthir.com/b4o00

yah, as i noted in my other reply, tab in that post seems to have been trying to solve the problem of sharing css across regular dom and shadow dom, rather than focusing on regular dom css and trying to remove the need for js and css preprocessors (which is what i'm more interested in). i could be wrong, as it's been a while since i read it.

Reply on news.ycombinator.com