Hacker News Reader

Comment by reaperducer | Hacker News Reader

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.

View on HN

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.

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)

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.

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

Reply on news.ycombinator.com