A First Look at `aspect-ratio`

Chris Coyier on (Updated on )

DigitalOcean provides cloud products for every stage of your journey. Get started with \$200 in free credit!

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.

Just dropping `aspect-ratio` on an element alone will calculate a height based on the `auto` width.

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.

If the element has both a height and width, `aspect-ratio` is ignored.

The combination of an explicit height and width is “stronger” than the aspect ratio.

Factoring in `min-*` and `max-*`

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.

Maybe it’s helpful to think of `aspect-ratio` as the weakest way to size an element?

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.