5 ms·

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and PostCSS plugins for years. I've recently gone back to only using vanilla CSS on personal projects and while there are niceties I do miss (nesting) it's refreshing not having to deal with config files or waiting for stuff to compile.

Semaphor 4y ago
Actual nesting is on the way [0], but for now you can already use :is() [1] in many cases. [0]: https://blog.openreplay.com/modern-css-selectors/ https://blog.openreplay.com/modern-css-selectors/ [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/:is https://developer.mozilla.org/en-US/docs/Web/CSS/:is
- toastercat 4y ago
  That's awesome. Thank you for sharing.
- laundermaf 4y ago
  :is() exclusively reduces nesting if your nest produces a single rule, which is the least common situation and is generally dealt with by just duplicating the selector rather than nesting.
  - runarberg 4y ago
    :is also has tighter specificity then a nested selector. which is a footgun for sure. However you can use :where instead, which is basically just :is without this footgun.
    - clairity 4y ago
      there's a subtlety missing: :is() selects the highest specificity from the selector list while :where() sets specificity to 0 for anything in the selector list. this leaves out the (admittedly narrow) case where you want the lowest matching specificity (in case 2+ selectors match) rather than just 0, which is probably what most folks would expect, just as we would tend to expect selector lists to be forgiving (following the principle of least surprise).
9dev 4y ago
The sweet spot for me is Vite, which comes with PostCSS built-in, and the nesting plug-in which follows the CSS spec. Vite takes care of the boring stuff, I can write vanilla CSS with nested declarations in it, and it just works.
- TheRealPomax 4y ago
  But what Vite didn't have to do anything because CSS already comes with nesting? CSS nesting was proposed over eleven years ago, and is only today finally making it into a single browser, behind an experimental flag. Three major preprocessing languages were invented and two of those (mostly) died off again in the mean time. We shouldn't need preprocessing here, we should have had nesting ten years ago =)
  - jozzy-james 4y ago
    to be fair, preprocessing comes with some other QoL things that I don't see CSS being able to support natively, namely mixins with math functions. edit: don't get me wrong, i'd love to be 100% native CSS, but there are some things where preprocessors shine
    - TheRealPomax 4y ago
      Right, but the only reason they shine is because they do something we all want but isn't in the spec. So getting it into the spec should absolutely be the goal here =D
noduerme 4y ago
I couldn't live without SCSS mixins, extensions and maps. The sheer tedium of doing it vanilla would drive me insane.
reaperducer 4y ago
I'm always excited by newer features to CSS that make older JS-only methods obsolete. I wonder if it's just about how some people's brains are wired. I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript. But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me the way CSS is. I read comments on HN frequently from people who are good a JS, but can't deal with CSS. I think it's just how some languages "click" with different people. Some are comfortable in Lisp, while others are AP/L, or Rust, or something else. Perhaps it's good to have multiple ways to achieving the same thing, rather than obsessing about one perfect/standard/preferred/"best practice" way of doing things.
- arrow7000 4y ago
  No. If you have to write styling in JS I can guarantee that it will be far more brittle, less performant, and way more susceptible to FOUCs, reflows, jank, and potentially deadlocks of conflicting resizing elements than the equivalent in CSS.
  - nwienert 4y ago
    Or you can author styles in JS and have them compiled to CSS. Then it's actually less brittle (fully typed), no fuoc, jank or deadlocks. https://vanilla-extract.style https://vanilla-extract.style https://tamagui.dev https://tamagui.dev
  - activitypea 4y ago
    All of which is preferable to an ever-growing spec whose pace makes it impossible for a newcomer to enter the browser space.
    - alvarlagerlof 4y ago
      JavaScript simply shouldn't handle a lot of layout. It's not running in sync with the layout engine in css.
purplerabbit 4y ago
Serious question: how do you refactor code when using nesting? In my experience it makes styles impossible to audit.
- cageface 4y ago
  Also not a fan of nesting. It makes it way to easy to create unmaintainable CSS spaghetti.
Beltalowda 4y ago
I used CSS tooling like LessCSS and SASS for years before switching back to regular CSS because I too wanted to simplify the build process (i.e. by not having one), and I found I didn't really miss the nesting so much. Mostly I solved it by writing things fairly concisely as: #menu { display: flex; justify-content: space-between; orange; border-bottom: 1px solid red; background-color: orange; color: #111; } #menu >a { font-size: 1.2em; margin-right: 1em; border: 1px solid #000; } etc. A bit of an unconventional way to write it, but I found it really helps keeping a bit of overview because so much more fits on your screen, and because CSS is fairly simple the extra density doesn't hurt readability all that much IMO. The biggest thing I missed was variables; but that's been solved now. Now I just want line comments (// ..). I dislike /* .. */ comments with a passion.
- abareplace 4y ago
  orange after space-between should be deleted
  - Beltalowda 4y ago
    Oops! Well, can't edit it now; too late for that. And doesn't really matter: it was just illustrative of the style.

Semaphor 4y ago

Actual nesting is on the way [0], but for now you can already use :is() [1] in many cases. [0]: https://blog.openreplay.com/modern-css-selectors/ https://blog.openreplay.com/modern-css-selectors/ [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/:is https://developer.mozilla.org/en-US/docs/Web/CSS/:is

toastercat 4y ago
That's awesome. Thank you for sharing.
laundermaf 4y ago
:is() exclusively reduces nesting if your nest produces a single rule, which is the least common situation and is generally dealt with by just duplicating the selector rather than nesting.
- runarberg 4y ago
  :is also has tighter specificity then a nested selector. which is a footgun for sure. However you can use :where instead, which is basically just :is without this footgun.
  - clairity 4y ago
    there's a subtlety missing: :is() selects the highest specificity from the selector list while :where() sets specificity to 0 for anything in the selector list. this leaves out the (admittedly narrow) case where you want the lowest matching specificity (in case 2+ selectors match) rather than just 0, which is probably what most folks would expect, just as we would tend to expect selector lists to be forgiving (following the principle of least surprise).

9dev 4y ago

The sweet spot for me is Vite, which comes with PostCSS built-in, and the nesting plug-in which follows the CSS spec. Vite takes care of the boring stuff, I can write vanilla CSS with nested declarations in it, and it just works.

TheRealPomax 4y ago
But what Vite didn't have to do anything because CSS already comes with nesting? CSS nesting was proposed over eleven years ago, and is only today finally making it into a single browser, behind an experimental flag. Three major preprocessing languages were invented and two of those (mostly) died off again in the mean time. We shouldn't need preprocessing here, we should have had nesting ten years ago =)
- jozzy-james 4y ago
  to be fair, preprocessing comes with some other QoL things that I don't see CSS being able to support natively, namely mixins with math functions. edit: don't get me wrong, i'd love to be 100% native CSS, but there are some things where preprocessors shine
  - TheRealPomax 4y ago
    Right, but the only reason they shine is because they do something we all want but isn't in the spec. So getting it into the spec should absolutely be the goal here =D

noduerme 4y ago

I couldn't live without SCSS mixins, extensions and maps. The sheer tedium of doing it vanilla would drive me insane.

reaperducer 4y ago

I'm always excited by newer features to CSS that make older JS-only methods obsolete. I wonder if it's just about how some people's brains are wired. I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript. But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me the way CSS is. I read comments on HN frequently from people who are good a JS, but can't deal with CSS. I think it's just how some languages "click" with different people. Some are comfortable in Lisp, while others are AP/L, or Rust, or something else. Perhaps it's good to have multiple ways to achieving the same thing, rather than obsessing about one perfect/standard/preferred/"best practice" way of doing things.

arrow7000 4y ago
No. If you have to write styling in JS I can guarantee that it will be far more brittle, less performant, and way more susceptible to FOUCs, reflows, jank, and potentially deadlocks of conflicting resizing elements than the equivalent in CSS.
- nwienert 4y ago
  Or you can author styles in JS and have them compiled to CSS. Then it's actually less brittle (fully typed), no fuoc, jank or deadlocks. https://vanilla-extract.style https://vanilla-extract.style https://tamagui.dev https://tamagui.dev
- activitypea 4y ago
  All of which is preferable to an ever-growing spec whose pace makes it impossible for a newcomer to enter the browser space.
  - alvarlagerlof 4y ago
    JavaScript simply shouldn't handle a lot of layout. It's not running in sync with the layout engine in css.

purplerabbit 4y ago

Serious question: how do you refactor code when using nesting? In my experience it makes styles impossible to audit.

cageface 4y ago
Also not a fan of nesting. It makes it way to easy to create unmaintainable CSS spaghetti.

Beltalowda 4y ago

I used CSS tooling like LessCSS and SASS for years before switching back to regular CSS because I too wanted to simplify the build process (i.e. by not having one), and I found I didn't really miss the nesting so much. Mostly I solved it by writing things fairly concisely as: #menu { display: flex; justify-content: space-between; orange; border-bottom: 1px solid red; background-color: orange; color: #111; } #menu >a { font-size: 1.2em; margin-right: 1em; border: 1px solid #000; } etc. A bit of an unconventional way to write it, but I found it really helps keeping a bit of overview because so much more fits on your screen, and because CSS is fairly simple the extra density doesn't hurt readability all that much IMO. The biggest thing I missed was variables; but that's been solved now. Now I just want line comments (// ..). I dislike /* .. */ comments with a passion.

abareplace 4y ago
orange after space-between should be deleted
- Beltalowda 4y ago
  Oops! Well, can't edit it now; too late for that. And doesn't really matter: it was just illustrative of the style.