Aspect-ratio is great

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.

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.

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.

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.

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.

https://developer.mozilla.org/en-US/docs/Web/CSS/inset

    .foo-component {
      --size: 20px;
      width: --size;
      height: --size;

      @media (hover: none) {
        --size: 40px;
      }
    }

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

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.

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

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`

    .foo {
        box-sizing: border-box;
        width: 10px;
        border 50px solid red;
    }

I'm sure the spec writers thought about the conflict already and decided what takes precedence.

   div {
     width:100px; height:100px; 
     aspect-ratio: 3 / 2;
   }

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%);
   }

   div {
     width:100px;
     height:100px; 
     aspect-ratio: 3 / 2;
   }

Your suggested replacement does not. What happens in the case below?

   div {
     width: height(100%); 
     height: width(66%);
   }

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.

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.

  div {
     —-width: 100px;
     —-ratio: 0.6666;
     width: var(—-width); 
     height: calc(var(—width) * var(—ratio));
   }

So even if you use this CSS rule, you should also set those width and height attributes. This allows the browsers to draw the correctly sized box whilst the image is still loading and whilst CSS hasn't kicked in yet.