Hacker News Reader

Comment by r_hoods_ghost | Hacker News Reader

"The text content in the third box is longer than the available space, so rather than maintaining the aspect ratio, the element expands vertically to fit the content... If we set an explicit height instead, the element doesn’t expand, but instead we get overflow"

Why? Why would you have different default behaviours if you have one of the dimensions set but not the other? Why would you not have this specified in another property, the overflow property perhaps? Oh look, lets define a new property and call it aspect ratio, and then lets ensure it doesn't maintain an element's aspect ratio if you have content that is going to overflow if you specify a width. This is what drives me mad about css, it's gotchas all the way down.

View on HN

> Why would you have different default behaviours if you have one of the dimensions set but not the other?

Basically: be there or be square (fill up the space or not, your choice), but if you show up there’s a dress code (you can only fill up the space as specified).

> Oh look, lets define a new property and call it aspect ratio, and then lets ensure it doesn't maintain an element's aspect ratio if you have content that is going to overflow if you specify a width. This is what drives me mad about css, it's gotchas all the way down.

There’s a lot I don’t like about CSS, but this is just the spec avoiding undefined behavior. No one is using aspect ratio for unbounded text in practice, they’re using it for media or a design system. Knowing how it behaves for edge cases is much better than having a protracted battle for years while vendors sort it out, with different assumptions in the wild.

If you set overflow: hidden it seems to do the trick on chrome at least

Right. As one would expect.

To emphasize this point, the alternatives would be ridiculed:

- overflow is assumed by default and constraining it is a whole bunch of necessary compromises, so my element maintains an aspect ratio but its content is overlapping siblings with the same aspect ratio. What the hell were they thinking?

- my element with 16:9 aspect ratio and the full text content of Moby Dick serialized as JSON was so wide my browser ate all my memory and swap, locked my computer up forcing a hard reboot

> full text content of Moby Dick serialized as JSON

Reminds me of when YouTube added a new comment system, but didn't specify a max length, and rendered the full text by default. People were spamming the Bible in comments.

You could instead just define the edge case behaviour so it is sane and consistent, e.g Text always overflows unless otherwise specified, or text is always clipped, rather than "lets stop the thing doing what it says it's doing". I swear the CSS spec considers "insane by default" To be a feature.

What you propose is insane by default. Clipped or overflowing text is almost never what you want.

The problem is that CSS is not (and continues not to be) designed to minimize such conflicting specifications, and does not provide a unified, explicit and systematic way to control conflict resolution.

It’s because there are 2 conflicting properties here: width and aspect-ratio. The user has set both. So when the content overflows, which one should be nullified? In this case they chose width to be maintained, and aspect ratio to be ignored.

If you want to maintain the aspect-ratio, just remove the explicit width. Then the box will be extremely wide and tall and will move to its own line. Probably not what the developer wants to achieve.

You could say that the default behaviour should be to clip the content, like overflow: hidden does. But in CSS, the content always has priority. And it will be (overflow:) visible by default. But as a user you can still choose to clip it (overflow: hidden), or make it scroll (overflow: scroll).

CSS has all the tools for you to choose the behaviour you want. And I think this aspect-ratio property is going to save me a lot of trouble.

I don't entirely understand this, but I think horizontal and vertical are often treated differently in CSS, yes? Like an item without width or height set will in some cases have width constrained by it's parent element, but height will not be (and can even cause parent element to grow). And I feel like it would end up weird and not what you wanted if it wasn't that way.

I may not have this exactly right, but i have an intuition that width and height are treated differently by CSS, and the aspect-ratio example is a consequence of some other fundamental rule/principle, not something unique to aspect-ratio.

Maybe someone else can explain this more specifically.

Because the convention is to scroll vertically and not horizontally, width is constrained but height is limitless in such a setup. Hence the differing treatment of width and height

> This is what drives me mad about css, it's gotchas all the way down.

And don't forget, every time a new half-baked shitty piece of the spec is added to poorly address something people have been complaining about for 15 years, tons of people will write articles (and these days go on Twitter) gushing over how amazing CSS is for granting these gifts from the gods.

Front-end really doesn't need to be as difficult to do day-to-day as back-end (concern balancing, i.e. perf vs storage vs cost vs fault tolerance vs maintainability vs monitoring vs etc, is the extremely difficult fundamental problem you always face in back-end/SRE/DevOps, but that's all mostly trivial in front-end, which is why being a React guru isn't anywhere near as rare as being able to scale a legacy PHP app to 1M DAU), it just has a lot of pointless complexity because these technologies are designed like absolute ass, and only inch forward by committee.

What you're overlooking is that CSS has to be backwards compatible to as great an extent as possible. It's not an option to abandon existing paradigms and what you perceive as "pointless complexity", because it would break the web. These things inch forward because they have huge ramifications for the internet.

Your rant about back-end/SRE/DevOps being inherently more difficult comes off as ill-informed. Where do you get the idea that balancing performance, cost, maintainability and monitoring are trivial on the front-end?

He probably thinks of frontend as

„my static blog and I cant get the text centered, damn css!“

instead of

„basically a full blown native application but written using browser APIs, with live collaboration features, GPU-using code where performance matters, oh and did i mention it must also work and look good on a mobile screen?“

Well, it doesn't have to be necessarily. At some point in the future they could decide to introduce versioned breaking changes.

Re: your second paragraph, I should have said "at scale".

I don't think I'm ill-informed, I've spent at least 5 years in each of front-end, back-end, and SRE/devops...I won't deny that there are some things that are really difficult on front-end (and in fact I don't like doing it because I don't find the challenges it offers very rewarding, though they take a lot of time), but in my experience, back-end is much, much harder at scale.

But the big distinction is that whereas frontend design/architecture/concerns are roughly the same no matter how many users you have, difficulty of back-end scales (about logarithmically) with traffic - 1k DAU is trivial, 100k is easy, 1M is "interesting", 10M is starting to get hard, 100M+ and you need to be top of your damn game (with a team to match) or you fail hard. Most projects don't have to ever reach the difficult regions, but to be perfectly honest my (non-side-project) backend work has all been in the large scale regime, so maybe for the average project across the industry the relative difficulty is about the same.

If you're in "git push heroku main" territory, then sure, frontend is probably a lot harder than backend.

To the first point, that's all fine and good, I think you're actually correct, I'm just tired of the fanboy-ism around CSS, and maybe I'm bitter because of how obnoxious the fanboys we're back when it was truly unusable. 10+ years ago there were people arguing vehemently that things like flexbox were completely pointless and in fact DANGEROUS because CSS was already perfect and could do anything as long as you weren't a noob, which was just ridiculous and wrong. I'll accept that things have gotten a lot better now and the stakes really are much higher w.r.t. changes.

CSS has always felt like a game of Q*bert to me, where you can't toggle one expected behavior without also affecting another unexpected behavior, and it's infuriating that this sort of thing persists into new specs.

Yea, this is an insane overlook in the spec

Reply on news.ycombinator.com