Oh hey! A brand new property that affects how a box is sized! That’s a big deal. There are lots of ways already to make an aspect-ratio sized box (and I’d say this custom properties based solution is the best), but none of them are particularly intuitive and certainly not as straightforward as declaring a single property.
So, with the impending arrival of aspect-ratio
(MDN, and not to be confused with the media query version), I thought I’d take a look at how it works and try to wrap my mind around it.
Shout out to Una where I first saw this and boy howdy did it strike interest in folks. Here’s me playing around a little.
aspect-ratio
on an element alone will calculate a height based on the auto
width.
Just dropping Without setting a width, an element will still have a natural auto width
. So the height can be calculated from the aspect ratio and the rendered width.
.el {
aspect-ratio: 16 / 9;
}
If the content breaks out of the aspect ratio, the element will still expand.
The aspect ratio becomes ignored in that situation, which is actually nice. That’s why the pseudo-element tactic for aspect ratios was popular, because it didn’t put us in dangerous data loss or awkward overlap territory when content got too much.
But if you want to constrain the height to the aspect ratio, you can by adding a min-height: 0;
:
If the element has either a height or width, the other is calculated from the aspect ratio.
So aspect-ratio
is basically a way of setting the other direction when you only have one.
aspect-ratio
is ignored.
If the element has both a height and width, The combination of an explicit height and width is “stronger” than the aspect ratio.
min-*
and max-*
Factoring in There is always a little tension between width
, min-width
, and max-width
(or the height versions). One of them always “wins.” It’s generally pretty intuitive.
If you set width: 100px;
and min-width: 200px;
then min-width
will win. So, min-width
is either ignored because you’re already over it, or wins. Same deal with max-width
: if you set width: 100px;
and max-width: 50px;
then max-width
will win. So, max-width
is either ignored because you’re already under it, or wins.
It looks like that general intuitiveness carries on here: the min-*
and max-*
properties will either win or are irrelevant. And if they win, they break the aspect-ratio
.
.el {
aspect-ratio: 1 / 4;
height: 500px;
/* Ignored, because width is calculated to be 125px */
/* min-width: 100px; */
/* Wins, making the aspect ratio 1 / 2 */
/* min-width: 250px; */
}
With value functions
Aspect ratios are always most useful in fluid situations, or anytime you essentially don’t know one of the dimensions ahead of time. But even when you don’t know, you’re often putting constraints on things. Say 50% wide is cool, but you only want it to shrink as far as 200px. You might do width: max(50%, 200px);
. Or constrain on both sides with clamp(200px, 50%, 400px);
.
This seems to work intuitively:
.el {
aspect-ratio: 4 / 3;
width: clamp(200px, 50%, 400px);
}
But say you run into that minimum 200px, and then apply a min-width
of 300px? The min-width
wins. It’s still intuitive, but it gets brain-bending because of how many properties, functions, and values can be involved.
aspect-ratio
as the weakest way to size an element?
Maybe it’s helpful to think of It will never beat any other sizing information out, but it will always do its sizing if there is no other information available for that dimension.
What if the image/object is like 459x395px or similar aspect ratio?
Is it advisable to make it aspect-ratio: 459/395 or is it idiotic? : )
Amazing!! I had in the past used javascript to achieve this.
Sample code:
var customWidthv = $('.slick-current img').width();
$('.slick-current .imagen-principal-portafolio').css({ 'height': 'calc(' + customWidthv+ 'px * 0.7 + 11px)' });
Thanks for the update!
Why did you use a variable and the declared the value inline instead of just declaring the aspect-ratio inline?
Okay, so, maybe I’m missing something here, but it appears your screenshots were taken using Chrome for Mac. I’M on Chrome for Mac, and I get nothing but blank screens in that initial CodePen.
“Okay,” thinks I, “maybe an extension?” …so I kill all my extensions. Same deal.
“Perhaps a version matter?” Consult MDN, who assert support is available on Chrome “only for mapped values” as of Chrome 79. Hmmm. I’m on 83.
“Okay, let’s see what the Chrome Platform Status report says?” You link to ”
Compute img/video aspect ratio from width and height HTML attributes” (https://chromestatus.com/feature/5695266130755584), which did, indeed, ship in v79, but “CSS aspect-ratio property” (https://chromestatus.com/feature/5738050678161408) is still listed as TBD (indeed, it’s in an “Assigned” state in the Chromium feature log).
So is this a pre-pre-preview from Canary or something? What am I missing here?