5 ms·

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; hei

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 https://sciter.com) has these width()/height() functions 10 or so years already.

lelandfe 5y ago
`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`
- c-smile 5y ago
  What if you have that width and aspect-ratio defined and in "galaxy far, far away" someone will define height for that element? 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?
  - AprilArcus 5y ago
    Don't expose your CSS classes to spooky action at a distance. Use a build system or CSS in JS library to hash your class names and keep them private. It's a terrible shame that CSS relies so heavily on globals (I'm looking at you, `@keyframes`), but as programmers we should all recognize them when we see it and avoid them by any means possible.
    - franga2000 5y ago
      > Use a build system or CSS in JS library to hash your class names and keep them private. Please don't. Human-readable and rarely changing class names are one of the few things keeping customization on the Web still possible. Just add an application name class selector to the beginning of each style block (perhaps as part of your build so you can do it for dependencies too) and put those classes on your body. For bonus points, put those classes as deep in the tree as reasonable and you have yourself scoped styles - all with zero JS and compiler fuckery. I've used this method to mix Bootstrap versions on one page as well as two completely different CSS frameworks. Obviously not something you want to do, but you might need to once in a while.
  - lelandfe 5y ago
    > instead of two properties that define box dimensions you now have now who knows how many props changing dimensions For border-box block elements, height and width are still absolutes (notwithstanding min-/max- values of the same). Protesting other box models is absolutely doable: just don't use 'em. Principle of least astonishment accomplished.
______-_-______ 5y ago
CSS already has to deal with conflicting values all over the place, for example: .foo { box-sizing: border-box; width: 10px; border 50px solid red; } What should the dimensions be? I'm sure the spec writers thought about the conflict already and decided what takes precedence.
- c-smile 5y ago
  inner box dimensions (in terms of CSS box model) are well specified in that case.
  - ______-_-______ 5y ago
    That's my point. `aspect-ratio` also has a spec, so the dimensions in your example are also well-specified.
    - c-smile 5y ago
      Of course it has spec. Just one more property in 200+ of them. That is no-brainer to add new property ... Problem is that each property introduced that way ads new dimension in compatibility matrix.
bfgeek 5y ago
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).
spartanatreyu 5y ago
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.
bryanrasmussen 5y ago
see my mention of the min, max, and clamp functions above https://news.ycombinator.com/item?id=30283162 https://news.ycombinator.com/item?id=30283162
baxuz 5y ago
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.
bbx 5y ago
Use CSS variables: div { —-width: 100px; —-ratio: 0.6666; width: var(—-width); height: calc(var(—width) * var(—ratio)); }
- spartanatreyu 5y ago
  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 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.

lelandfe 5y ago

`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`

c-smile 5y ago
What if you have that width and aspect-ratio defined and in "galaxy far, far away" someone will define height for that element? 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?
- AprilArcus 5y ago
  Don't expose your CSS classes to spooky action at a distance. Use a build system or CSS in JS library to hash your class names and keep them private. It's a terrible shame that CSS relies so heavily on globals (I'm looking at you, `@keyframes`), but as programmers we should all recognize them when we see it and avoid them by any means possible.
  - franga2000 5y ago
    > Use a build system or CSS in JS library to hash your class names and keep them private. Please don't. Human-readable and rarely changing class names are one of the few things keeping customization on the Web still possible. Just add an application name class selector to the beginning of each style block (perhaps as part of your build so you can do it for dependencies too) and put those classes on your body. For bonus points, put those classes as deep in the tree as reasonable and you have yourself scoped styles - all with zero JS and compiler fuckery. I've used this method to mix Bootstrap versions on one page as well as two completely different CSS frameworks. Obviously not something you want to do, but you might need to once in a while.
- lelandfe 5y ago
  > instead of two properties that define box dimensions you now have now who knows how many props changing dimensions For border-box block elements, height and width are still absolutes (notwithstanding min-/max- values of the same). Protesting other box models is absolutely doable: just don't use 'em. Principle of least astonishment accomplished.

______-_-______ 5y ago

CSS already has to deal with conflicting values all over the place, for example: .foo { box-sizing: border-box; width: 10px; border 50px solid red; } What should the dimensions be? I'm sure the spec writers thought about the conflict already and decided what takes precedence.

c-smile 5y ago
inner box dimensions (in terms of CSS box model) are well specified in that case.
- ______-_-______ 5y ago
  That's my point. `aspect-ratio` also has a spec, so the dimensions in your example are also well-specified.
  - c-smile 5y ago
    Of course it has spec. Just one more property in 200+ of them. That is no-brainer to add new property ... Problem is that each property introduced that way ads new dimension in compatibility matrix.

bfgeek 5y ago

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

spartanatreyu 5y ago

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.

bryanrasmussen 5y ago

see my mention of the min, max, and clamp functions above https://news.ycombinator.com/item?id=30283162 https://news.ycombinator.com/item?id=30283162

baxuz 5y ago

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.

bbx 5y ago

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

spartanatreyu 5y ago
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 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.