"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"<p>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.
Oh my god.<p>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.”<p>Hours and hours. And hours.
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.<p>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'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.<p>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.
aspect-ratio is actually a great mistake - it breaks CSS box model again (after flexbox).<p>What should be the dimensions of this<p><pre><code> div {
width:100px; height:100px;
aspect-ratio: 3 / 2;
}
</code></pre>
?<p>Instead, there should be "functions" width(N%) and height(N%) and so<p><pre><code> 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%);
}
</code></pre>
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.<p>For that matter, Sciter (<a href="https://sciter.com" rel="nofollow">https://sciter.com</a>) has these width()/height() functions 10 or so years already.
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 <a href="https://caniuse.com/mdn-css_properties_aspect-ratio" rel="nofollow">https://caniuse.com/mdn-css_properties_aspect-ratio</a>.
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)
Not really. It's still tied to the element's width and will overflow vertically. Even if using a flex/grid container with a different axis, it will only constraint the aspect ratio to its width.<p>Which means that if you want to have something like a video player in the viewport like YouTube does, or lightbox-style previews which keep the entire media element in viewport you'll still have to use JS to limit the element's height, or if the design allows for it, use viewport height units + calc.
I was under the impression that this has been a thing for a long while, but I checked and it's actually been available in mainstream browser versions only since January 2021 (September for Safari, and just nine days ago for Chrome on Android). Combined global usage for supported platforms is around 84%.<p><a href="https://caniuse.com/mdn-css_properties_aspect-ratio" rel="nofollow">https://caniuse.com/mdn-css_properties_aspect-ratio</a>
I really want to use aspect-ratio, but a recent thread on HN, that now I can't find, has me worried that I shouldn't be counting on CSS until its been supported by the browsers for a couple years.<p>The recent thread was about all the reasons that even "evergreen" browsers might still have plenty of people using old versions, and was on a thread about a Chromebox still in use that could not have it's version of Chrome updated.
Articles like that always make me smile, because I imagine like 20 years ago someone would write a lenghty blog post about GtkAspectFrame or GtkHBox and its “expand” and “fill” child properties. Or about GtkSizeGroup (which css still can’t figure out). Gtk is awesome, so amazing!
this is great, but what sticks out to me is how quickly this seems to have been rolled out. Unless I'm misreading something, this went from first public draft [1] to full support [2] in less than two years?<p>Maybe I just haven't been paying attention to the rate new CSS features, but from my perspective this totally just dropped out of the sky. Here's hoping we can continue this pace.<p>[1] <a href="https://www.w3.org/TR/2020/WD-css-sizing-4-20200526" rel="nofollow">https://www.w3.org/TR/2020/WD-css-sizing-4-20200526</a>
[2] <a href="https://caniuse.com/?search=aspect-ratio" rel="nofollow">https://caniuse.com/?search=aspect-ratio</a>
If you just want this to avoid layout shift, you're still better off using explicit width and height attributes (on the img tag), because it is per-image in the HTML itself, not in a common CSS declaration. Is that right?
Good read.<p>It’s kinda funny that, on a CSS focused site, the position of the “latest” article label on the homepage is set above that of the site logo and navigation bar.<p>It’s nice to know even CSS experts make mistakes ¯\_(ツ)_/¯.