"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.
> 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.
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
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.
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?
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.
The old answer, for those curious, was a padding-bottom with the aspect ratio expressed as a percentage: https://jsfiddle.net/9yLkm0tu/
This works because padding percentages are calculated based on width – making this, at the time, the only practical way to form a relationship between an element's height and width. Thierry Koblentz coined this "intrinsic ratios" back in '09: https://alistapart.com/article/creating-intrinsic-ratios-for...
Some people call it a hack – it's just a narrow application of the spec.
This is really amazing. The last CSS thing I learned about was flex-box and it so vastly improved my side projects. I'm sure this will come quite handy too.
What are more such things which you love about CSS but only learned about recently? Can greatly benefit CSS dinosaurs like me who know CSS but haven't really kept up on the recent developments.
Personally I think the most useful 'new' things in CSS that hardly anyone uses yet are the min, max, and Clamp functions.
I wrote about them here https://blog.logrocket.com/min-max-clamp-css-functions/ - there are some real embarrassments in that article (probably due to me being busy with other things at the time of writing, and being outside my comfort zone [dealing with design]) - example silly statement: "these functions can accept anything that is a number or a calculable value, like the length of a variable, as an input." length of a variable? WTF did I write that for!?!
I could also probably have saved my time because the day after I finished writing it I found this post https://ishadeed.com/article/css-min-max-clamp/ which makes a lot of the same points, less verbosely, and better, with much nicer looking examples because I guess this guy has a design sense.
on edit: I mean I am just jealous of the examples he made, I sweated trying to make something up to show the power of the functions and explain their use and I don't think I did a good job of it, didactically, and his examples were really good. Probably he sweated to, but they look effortless.
Do these functions make min-width and min-height obsolete? Or is there still any reason to use those instead of min()/max()/clamp()?
Edit: just noticed the articles you linked have nice examples of combining the two (should've read first), and it makes perfect sense since min-width/min-height deal with how elements grow to fit their contents, while something like `width: clamp(...)` would be declaring the width instead.
CSS grids are a layout revolution. Quite difficult to learn, but very powerful. It may take years before the community understands all that it has to offer.
Container queries are a game changer, although not fully ready across browsers yet.
CSS variables have been around for a while now, but still considered fairly new. CSS nesting is also around the corner. When you combine these two things, you can start considering to drop CSS preprocessors like SCSS.
CSS layers is brand new and may be useful when working with design language systems.
And as an unimportant but fun last one: you can now address colors outside the RGB color space.
i guarantee the next thing you want to learn is `grid`. It takes a bit of time to get your head around, then you realize you can do just about anything, fluid-responsively.
I've stopped working on web projects about ten years ago and it's still shocking how much was missing from even the most basic things compared to other UI frameworks that often had it for decades.
It's quite sad that there's apparently no other direction than "JavaScript and the web will replace every type of application eventually". I mean look how well Microsoft Word (native) works compared to Microsoft Teams (some JS hodgepodge). And not just the day by day use, but also stuff like AppleScript support. Especially highlighted by the stand still we used to have on mobile computer CPU's until recently. Everything just got slower and slower.
Thank you for this comment. It's scary to think that majority of the tech-savvy people in the world never question sanity of web stack and don't see how badly it is unfit for making UI apps.
I switched to Flutter few years ago, and now making all apps with it (which gives web version out of the box along with native ios/android/linux/windows/mac). Hard to believe people still wasting their time on CSS/JS/HTML for new projects and call hacks like this "amazing".
aspect-ratio is actually a great mistake - it breaks CSS box model again (after flexbox).
What should be the dimensions of this
div {
width:100px; height:100px;
aspect-ratio: 3 / 2;
}
?
Instead, there should be "functions" width(N%) and height(N%) and so
div {
width:100px;
height: width(66%);
}
div {
height:100px;
width: height(150%);
}
div {
height:40px;
line-height: height(100%);
}
div {
width:100px;
margin: width(10%);
}
Therefore, instead of one more property that "solves" only one particular problem we will have bunch of solutions by adding just two pseudo-functions. And without breaking box model in very nasty way.
For that matter, Sciter (https://sciter.com) has these width()/height() functions 10 or so years already.
div {
width:100px; height:100px;
aspect-ratio: 3 / 2;
}
This is all well specified and doesn't "break" the box-model in anyway. Anytime there is a definite width/height specified the box well respect that width/height. The aspect-ratio is lowest on the constraint priority list if you like.
Internally in browser engines there was already an aspect-ratio for replaced elements, and these elements already had to (in a slightly different way) deal with width/height/min-width/min-height/etc. aspect-ratio was exposing and slightly generalizing what engines had already.
The example you give with allowing the width() function for margin, raises a lot of questions. E.g. you could have something like:
div {
width: auto;
margin: width(10%);
}
This gets into "difficult" territory very quickly (even more complex with calc/min/max/clamp/etc) as you'd need to try and solve a multi-variable equation. (Width depends on the size of the margins, and margins depends on the width).
`aspect-ratio` specifies the preferred ratio. It gets used in cases where sizing values are intrinsic.
In your first example, it would be overruled by the defined sizing values. I think that's fine, personally. Further, I don't see how it breaks the box model – esp. given that the spec that defines box model also defines `aspect-ratio`
Your "should be functions" suggestion is far more problematic than aspect-ratio.
div {
width:100px;
height:100px;
aspect-ratio: 3 / 2;
}
In your first example (shown above), aspect-ratio has a clear way to solve conflicts: aspect-ratio does not overwrite explicitly defined dimensions, it can only affect implicit dimensions.
Your suggested replacement does not. What happens in the case below?
div {
width: height(100%);
height: width(66%);
}
Problems with the function approach that I can think of off the top of my head:
1. There is no logical way to say that one function should override another in the case of circular constraints.
2. It relies on percentages instead of fractions, this leads to developers having to either needing to nest an extra calc function within to deal with a fraction, or rely on precomputed magic numbers which are never a good thing. The new aspect-ratio rule means new developers will never need to commit the fact that a height of 56.25% the width results in a 16:9 ratio. If we're using a fraction instead, why create two functions that fall prey to the other problems listed instead of just putting it on `aspect-ratio`.
3. Naming collisions. Something perhaps best avoided, lest we encounter strange lines like: `height: height(var(--height));
4. It relies on percentages for widths and heights. This is just going to add more even confusion about the conditions and gotchas pertaining to percentage units on the width and height properties. For example: `height: 56.25%;` sets its height based on the width of the element (unlike `width: 56.25%` which sets it width based on the width of its containing element) except in the cases of various `position: absolute;` and `position: relative;` caveats on the element in question and its parents.
5. It relies on using widths and heights instead of focusing on lengths along inline and block axes. What happens when the writing direction changes to vertical? Do the widths and heights switch or not?
The aspect-ratio approach is fine. In fact I'd go out of my way to say it's better than fine. All the problems of different approaches presented and debates held during the formation of the standard have resulted in a great css addition that removes many annoyances that developers have had with no additional downsides.
Exactly. The aspect-ratio property works the same way as the padding hack does. It calculates the height based on the rendered width. You can't do it the other way around, even if using a different axis inside a flex or grid element.
You still can't have a div in the middle of the screen, which will have a maximum (intrinsic) width/height, a set aspect ratio, and which will respond to resizing the window vertically. It will simply overflow.
You have to be very careful around doing this. If the unit assigned to length variable changed from pixels to percentage, you may end up with unintended and hard to debug behaviour.
Look at points: 2, 4 & 5 on my comment here: https://news.ycombinator.com/item?id=30282458. Point 4 in particular since there are so many gotchas with percentage units. Someone else could change the styles for a different element and it would break your element's styles in a hard to debug way.
This has been one of my absolute favorite CSS improvements in recent years. Upon first seeing it people don't typically pick up on the magnitude of benefit that the feature offers. Once it sets in, however, you start seeing it everywhere. Image dimension management had been an enduring problem throughout CSS history but now aspect ratio is supported across the board https://caniuse.com/mdn-css_properties_aspect-ratio.
I have used aspect-ration in production and I concur. Say you want to display a user avatar, but the user might not have uploaded their avatar, so you fallback with a colored box (basically a div) with the user’s initials instead (or—in practice—your best guess of their initials). aspect-ratio will cover both of these. So you can you don’t need to set a different weight or padding depending of if you have an image or a div.
I'm so happy to see directives like these making it into css! It's great to have super granular control of every dimension and stuff, but in terms of creating layouts etc it really needs higher abstraction properties like this. I think this is why css was always so frustrating for me: caring about the technical side of things instead of the actual design implementation, which I now realize is not entirely my fault, but rather by design of the sepcs. (I still need to learn about layout fundamentals etc, but this certainly helps getting a grasp of things)
Readit News
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.
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.
- 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
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 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.
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.
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?
I spent so freaking much time trying to solve “make the outermost div fill the screen of the device but always keep it a specific ratio.”
Hours and hours. And hours.
This works because padding percentages are calculated based on width – making this, at the time, the only practical way to form a relationship between an element's height and width. Thierry Koblentz coined this "intrinsic ratios" back in '09: https://alistapart.com/article/creating-intrinsic-ratios-for...
Some people call it a hack – it's just a narrow application of the spec.
What are more such things which you love about CSS but only learned about recently? Can greatly benefit CSS dinosaurs like me who know CSS but haven't really kept up on the recent developments.
I wrote about them here https://blog.logrocket.com/min-max-clamp-css-functions/ - there are some real embarrassments in that article (probably due to me being busy with other things at the time of writing, and being outside my comfort zone [dealing with design]) - example silly statement: "these functions can accept anything that is a number or a calculable value, like the length of a variable, as an input." length of a variable? WTF did I write that for!?!
I could also probably have saved my time because the day after I finished writing it I found this post https://ishadeed.com/article/css-min-max-clamp/ which makes a lot of the same points, less verbosely, and better, with much nicer looking examples because I guess this guy has a design sense.
on edit: I mean I am just jealous of the examples he made, I sweated trying to make something up to show the power of the functions and explain their use and I don't think I did a good job of it, didactically, and his examples were really good. Probably he sweated to, but they look effortless.
Edit: just noticed the articles you linked have nice examples of combining the two (should've read first), and it makes perfect sense since min-width/min-height deal with how elements grow to fit their contents, while something like `width: clamp(...)` would be declaring the width instead.
People are finding all sorts of fun things to do with it: https://web.dev/one-line-layouts/ and https://moderncss.dev/3-popular-website-heroes-created-with-...
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Scroll_...
https://developer.mozilla.org/en-US/docs/Web/CSS/inset
Container queries are a game changer, although not fully ready across browsers yet.
CSS variables have been around for a while now, but still considered fairly new. CSS nesting is also around the corner. When you combine these two things, you can start considering to drop CSS preprocessors like SCSS.
CSS layers is brand new and may be useful when working with design language systems.
And as an unimportant but fun last one: you can now address colors outside the RGB color space.
It's quite sad that there's apparently no other direction than "JavaScript and the web will replace every type of application eventually". I mean look how well Microsoft Word (native) works compared to Microsoft Teams (some JS hodgepodge). And not just the day by day use, but also stuff like AppleScript support. Especially highlighted by the stand still we used to have on mobile computer CPU's until recently. Everything just got slower and slower.
I switched to Flutter few years ago, and now making all apps with it (which gives web version out of the box along with native ios/android/linux/windows/mac). Hard to believe people still wasting their time on CSS/JS/HTML for new projects and call hacks like this "amazing".
What should be the dimensions of this
?Instead, there should be "functions" width(N%) and height(N%) and so
Therefore, instead of one more property that "solves" only one particular problem we will have bunch of solutions by adding just two pseudo-functions. And without breaking box model in very nasty way.For that matter, Sciter (https://sciter.com) has these width()/height() functions 10 or so years already.
Internally in browser engines there was already an aspect-ratio for replaced elements, and these elements already had to (in a slightly different way) deal with width/height/min-width/min-height/etc. aspect-ratio was exposing and slightly generalizing what engines had already.
The example you give with allowing the width() function for margin, raises a lot of questions. E.g. you could have something like:
This gets into "difficult" territory very quickly (even more complex with calc/min/max/clamp/etc) as you'd need to try and solve a multi-variable equation. (Width depends on the size of the margins, and margins depends on the width).In your first example, it would be overruled by the defined sizing values. I think that's fine, personally. Further, I don't see how it breaks the box model – esp. given that the spec that defines box model also defines `aspect-ratio`
What about good old principle of least astonishment? Not for us anymore?
That's the problem - instead of two properties that define box dimensions you now have now who knows how many props changing dimensions
Why the hell property named align(sic!) `align-items: stretch;` shall change box dimensions? And what to do with width/height then?
Your suggested replacement does not. What happens in the case below?
Problems with the function approach that I can think of off the top of my head:1. There is no logical way to say that one function should override another in the case of circular constraints.
2. It relies on percentages instead of fractions, this leads to developers having to either needing to nest an extra calc function within to deal with a fraction, or rely on precomputed magic numbers which are never a good thing. The new aspect-ratio rule means new developers will never need to commit the fact that a height of 56.25% the width results in a 16:9 ratio. If we're using a fraction instead, why create two functions that fall prey to the other problems listed instead of just putting it on `aspect-ratio`.
3. Naming collisions. Something perhaps best avoided, lest we encounter strange lines like: `height: height(var(--height));
4. It relies on percentages for widths and heights. This is just going to add more even confusion about the conditions and gotchas pertaining to percentage units on the width and height properties. For example: `height: 56.25%;` sets its height based on the width of the element (unlike `width: 56.25%` which sets it width based on the width of its containing element) except in the cases of various `position: absolute;` and `position: relative;` caveats on the element in question and its parents.
5. It relies on using widths and heights instead of focusing on lengths along inline and block axes. What happens when the writing direction changes to vertical? Do the widths and heights switch or not?
The aspect-ratio approach is fine. In fact I'd go out of my way to say it's better than fine. All the problems of different approaches presented and debates held during the formation of the standard have resulted in a great css addition that removes many annoyances that developers have had with no additional downsides.
I'm sure the spec writers thought about the conflict already and decided what takes precedence.
You still can't have a div in the middle of the screen, which will have a maximum (intrinsic) width/height, a set aspect ratio, and which will respond to resizing the window vertically. It will simply overflow.
Look at points: 2, 4 & 5 on my comment here: https://news.ycombinator.com/item?id=30282458. Point 4 in particular since there are so many gotchas with percentage units. Someone else could change the styles for a different element and it would break your element's styles in a hard to debug way.
It'll be better to use aspect-ratio.