3 ms·

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

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.

xboxnolifes 4y ago
Nesting is basically the only reason I always use sass, even in small projects. Will be happy when that comes to css.
- JimDabell 4y ago
  That’s been available for years with PostCSS. You can use a lot of tomorrow’s CSS today with PostCSS Preset Env.
  - xboxnolifes 4y ago
    Aren't both sass and postcss supersets of css that require transformation plugins? What am I gaining from switching from sass to postcss here?
    - elondaits 4y ago
      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.
- purplerabbit 4y ago
  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.
  - MrJohz 4y ago
    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.
no_wizard 4y ago
There was a mixins proposal for `@apply`[0][1] but it was unfortunately dropped [0]: https://tabatkins.github.io/specs/css-apply-rule/ https://tabatkins.github.io/specs/css-apply-rule/ [1]: https://www.xanthir.com/b4o00 https://www.xanthir.com/b4o00
- clairity 4y ago
  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.
spankalee 4y ago
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 https://github.com/w3c/csswg-drafts/issues/3714
- clairity 4y ago
  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.

xboxnolifes 4y ago

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

JimDabell 4y ago
That’s been available for years with PostCSS. You can use a lot of tomorrow’s CSS today with PostCSS Preset Env.
- xboxnolifes 4y ago
  Aren't both sass and postcss supersets of css that require transformation plugins? What am I gaining from switching from sass to postcss here?
  - elondaits 4y ago
    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.
purplerabbit 4y ago
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.
- MrJohz 4y ago
  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.

no_wizard 4y ago

There was a mixins proposal for `@apply`[0][1] but it was unfortunately dropped [0]: https://tabatkins.github.io/specs/css-apply-rule/ https://tabatkins.github.io/specs/css-apply-rule/ [1]: https://www.xanthir.com/b4o00 https://www.xanthir.com/b4o00

clairity 4y ago
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.

spankalee 4y ago

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 https://github.com/w3c/csswg-drafts/issues/3714

clairity 4y ago
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.