4 ms·

"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 co

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

selfmodruntime 5y ago
Yea, this is an insane overlook in the spec
eyelidlessness 5y ago
> 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.
- jontro 5y ago
  If you set overflow: hidden it seems to do the trick on chrome at least
  - eyelidlessness 5y ago
    Right. As one would expect.
- eyelidlessness 5y ago
  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
  - torgard 5y ago
    > 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.
- r_hoods_ghost 5y ago
  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.
  - frosted-flakes 5y ago
    What you propose is insane by default. Clipped or overflowing text is almost never what you want.
- layer8 5y ago
  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.
lvncelot 5y ago
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.
bbx 5y ago
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.
cornel_io 5y ago
> 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.
- muspimerol 5y ago
  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?
  - axiosgunnar 5y ago
    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?“
  - dbbk 5y ago
    Well, it doesn't have to be necessarily. At some point in the future they could decide to introduce versioned breaking changes.
  - 5y ago
jrochkind1 5y ago
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.
- darepublic 5y ago
  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

selfmodruntime 5y ago

Yea, this is an insane overlook in the spec

eyelidlessness 5y ago

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

jontro 5y ago
If you set overflow: hidden it seems to do the trick on chrome at least
- eyelidlessness 5y ago
  Right. As one would expect.
eyelidlessness 5y ago
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
- torgard 5y ago
  > 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.
r_hoods_ghost 5y ago
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.
- frosted-flakes 5y ago
  What you propose is insane by default. Clipped or overflowing text is almost never what you want.
layer8 5y ago
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.

lvncelot 5y ago

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.

bbx 5y ago

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.

cornel_io 5y ago

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

muspimerol 5y ago
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?
- axiosgunnar 5y ago
  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?“
- dbbk 5y ago
  Well, it doesn't have to be necessarily. At some point in the future they could decide to introduce versioned breaking changes.
- 5y ago

jrochkind1 5y ago

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.

darepublic 5y ago
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