[HN Gopher] Speaking Up for Sass (2021)
___________________________________________________________________
Speaking Up for Sass (2021)
Author : lioeters
Score : 32 points
Date : 2022-10-22 16:11 UTC (6 hours ago)
(HTM) web link (www.brycewray.com)
(TXT) w3m dump (www.brycewray.com)
| KronisLV wrote:
| I still use Sass for some projects and find it perfectly
| sufficient in most cases. Because of this, I don't really see
| moving away from it anytime soon: it feels like a nice little
| addition on top of CSS, that's not overbearing and most people
| can also get up to speed with the features that it provides.
|
| Nesting being one of the things that I think CSS should have had
| out of the box, but that might change for the better eventually:
| https://www.w3.org/TR/css-nesting-1/
|
| That said, various CSS component frameworks, utility class
| frameworks (or libraries) also seem nice, from Tailwind or maybe
| PrimeFlex (which feels nice with PrimeVue or PrimeReact), all the
| way back to aspects of that approach in Bootstrap.
|
| Things can get a little bit messy when you mix both of the
| approaches a lot, though. Parts of the style are in the utility
| classes but for some reason you also have your own custom classes
| and so on, which I've seen sometimes.
| fleddr wrote:
| I feel obliged to share a gotcha regarding nesting...
|
| The idea of nesting in SASS/SCSS is that you need a combination
| of selectors, and you don't want to repeatedly type out the first
| one.
|
| What I often see though is developers using it as grouping
| structure, closely mimicking the nesting of the markup they're
| working with. This is massively convenient from an authoring
| point of view, but it leads to issues.
|
| For complicated components, I've seen output consisting of 12
| selectors after each other, whilst only 2 would be needed. Not
| only does this lead to verbose output, it also makes that style
| rule extremely specific. In case you ever need to overrule it,
| you'd need 13 selectors or an !important.
|
| To illustrate: .selector1 .selector2 ........all the way up to
| .selector 12
|
| Or: .selector1 .selector12
|
| Example 2 is what you want. You got your parent scope and after
| that it doesn't matter where .selector12 is in the markup,
| assuming you use something like BEM. The 10 nesting levels in
| between are completely pointless.
| kuramitropolis wrote:
| brycewray wrote:
| Author here. Thanks to lioeters for posting this.
| seanwilson wrote:
| > Tailwind adherents say this isn't a problem because, once you
| recognize that you're re-using certain Tailwind classes too
| frequently, you then simply extract them to reusable components
| and then @apply them, as the Tailwind documentation suggests. I
| agree that this is a workable strategy, but my own experience
| suggests it can get out of hand quickly, even in a small project.
|
| The @apply approach is really only for single-div components or
| as a last resort. The default way you should be reusing styles
| when using utility classes is to extract each component into its
| own HTML template file so you can update its styles from a
| central place e.g. your hero header might go in a file called
| hero-header.html along with all the relevant HTML + utility
| classes so you can update it from a central place.
|
| I think this is really central to understanding Tailwind's claim
| of being scalable when compared to the traditional way of using
| CSS classes. The examples here are worth considering carefully
| (especially if your knee-jerk reaction is "it's just inline
| styles and inline styles are bad practice!"):
|
| https://tailwindcss.com/docs/reusing-styles
|
| https://tailwindcss.com/docs/utility-first
|
| > There are numerous pieces on the web saying that one of the
| biggest hassles in dealing with code is naming things (e.g.,
| variables, functions, and CSS classes), and that this is a pain
| which Tailwind can remedy by keeping you from having to name more
| than a handful of CSS classes.
|
| You'll still have names for your component files and you can add
| comments to the HTML if needed. Will you really miss classes like
| `hero-inner-container-wrapper' that you were forced to add to a
| `div` to apply a single class? A lot of `div`s like this won't
| have meaningful names because they're purely presentational or
| were only added to get around some CSS limitation.
| RobotToaster wrote:
| I thought this article was going to be a defence of being cheeky.
| [deleted]
| pier25 wrote:
| Sass is awesome and still the most popular way of writing CSS
| according to the State of CSS surveys.
|
| A day might come when we'll be able to just write vanilla CSS but
| we're not there yet.
| ravenstine wrote:
| > A day might come when we'll be able to just write vanilla CSS
| but we're not there yet.
|
| Ummm... what? You _can_ already just write vanilla CSS. It
| doesn 't have all the features of Sass, but it's perfectly
| usable, especially if cascading is used sparingly.
| danielvaughn wrote:
| Pretty sure OP was being sarcastic
| pier25 wrote:
| When I mean vanilla CSS I mean just that. No bundler or
| anything else, like we did in the good old days.
|
| Even if using the latest features at least a bundler is still
| needed for most projects.
| spankalee wrote:
| Lots of people write large-scale vanilla CSS today, especially
| in the Lit community where we have native style scoping and
| where CSS strings are embedded in JS modules so we get proper
| import-based loading, sharing, and bundling.
| pier25 wrote:
| lol CSS in JS is definitely not vanilla CSS.
| clairity wrote:
| 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 wrote:
| Nesting is basically the only reason I always use sass, even in
| small projects. Will be happy when that comes to css.
| JimDabell wrote:
| That's been available for years with PostCSS. You can use a
| lot of tomorrow's CSS today with PostCSS Preset Env.
| xboxnolifes wrote:
| Aren't both sass and postcss supersets of css that require
| transformation plugins? What am I gaining from switching
| from sass to postcss here?
| purplerabbit wrote:
| 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 wrote:
| 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 wrote:
| 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
| clairity wrote:
| 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 wrote:
| 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
| clairity wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-22 23:01 UTC)