Hacker News Reader

Comment by toastercat | Hacker News Reader

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.

View on HN

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.

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.

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://tamagui.dev

All of which is preferable to an ever-growing spec whose pace makes it impossible for a newcomer to enter the browser space.

JavaScript simply shouldn't handle a lot of layout. It's not running in sync with the layout engine in css.

There has been some movement to handle CSS layout in JavaScript (running in a service worker, so that it cannot have state, but otherwise fully in sync with the layout), as part of the “Houdini” effort: https://www.w3.org/TR/css-layout-api-1/

(Disclosure: I work on the style team in Chromium)

Only one of those options stands a chance of rendering in my browser.

I don't understand either one. I use React (while technically pure JS, I assume this isn't what you mean) and calculate most of the sizes manually, just passing width and height as props into my elements. People tell me that's dumb, but it's always worked, and I don't have to keep up with this topic of CSS that doesn't really interest me. I've tried the "correct" flexbox way too, and it wasn't easier.

One particular thing about CSS... <img> seems to never behave in any kind of auto-sizing container the same way a regular div would; it seems to need pixel dimensions to work as expected in all scenarios, especially when things are resizing dynamically. Idk how other people deal with that. That alone was my motivation for trying things my own way.

I did something similar developing an app long ago for the iPhone 4. Calculated all my dimensions in C macros cause AutoLayout made no sense. Tons of apps using AutoLayout broke anyway when the new screen sizes came out, but my app was fine. "Math is math."

> Idk how other people deal with that.

CSS handles it just fine. That's how they deal with it.

For img you set one of width/height attributes on the image or the aspect ratio CSS property (for page stability during early loading, actual dimensions are preferred), then max-width: 100%; height: auto to scale according to horizontal space, or max-height:100%; width:auto to scale according to vertical space.

The additional complexity of images is that you nearly always want to maintain the aspect ratio, whereas a p or a div can be a radically different shape depending on the amount of content and viewport size and only have issues at the extremes (like very long lines at 4k@1x, or one word per line at high zoom)

I'll have to set up my sandbox in React again to find the exact problem. I wanted it to do what most would expect: img should size like a flexbox'd div and display the image with the original aspect ratio, either zooming or adding blank area to fit, depending on the use case. This div's width and height might be resized as the outer divs respond to changes. Should be easy.

Naturally I first tried making an outer flexbox'd div then putting a {width: 100%, height: 100%} img inside that with whatever fit option. And several variations on that, including the "width: auto" or "width: 0" tricks. Somehow it'd always either go outside the div boundaries or exhibit some other glitchy behavior. On top of that, there's the issue you mentioned where the image isn't loaded yet, causing funky resizing beforehand. You're simply better off with exact pixel dimensions.

There are tons of SO questions from confused individuals in my same situation, all with different answers that only work in certain scenarios. For example https://stackoverflow.com/a/21103679 which only works for auto-resizing the width, not the height. I think your suggestion has a similar caveat.

Meanwhile for me CSS is like the MS Word memes. Things that worked just break one day, certain options make other seemingly compatible options do nothing, and some settings just don't do what you'd guess from their name.

Almost everything can be made to look correctly but somehow the right solution is the last one I'd ever think of.

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/

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/:is

That's awesome. Thank you for sharing.

: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.

: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.

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).

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.

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 =)

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

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

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.

orange after space-between should be deleted

Oops! Well, can't edit it now; too late for that. And doesn't really matter: it was just illustrative of the style.

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

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

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

Reply on news.ycombinator.com