why not CSS property?

[determin1st]

it can be synced later with transforms. when you size dom container with transforms, contents get screwed

[eeeps]

The CSSWG is planning on spec'ing a way to set extrinsic aspect ratios soonish: https://twitter.com/fantasai/status/1024041682805829632

I think this is the relevant issue: w3c/csswg-drafts#333

In my mind, CSS should stay out of the business of setting intrinsic sizes (which are really a question of content), and should keep to extrinsic sizes (which are about how to style that content). Not sure I totally understand what you're talking about, re: transforming a DOM container, though. Would a CSS aspect-ratio property allow you to solve it?

[determin1st]

i think, im not properly formulating yet, because i dont understand/get the problem i have to solve in the future. my point is uniformity of aspect-ratio. take a look at this pen:

https://codepen.io/osublake/pen/xYMeKP?editors=0110

if the aspect-ratio remove the need to counter-scale inner container, it would be okay.

[eeeps]

Not totally sure what you're doing with the outer/inner containers (what do you mean “counter-scale”?), but, re: aspect ratios, if you know the width/height/aspect-ratio of your container, and want to clip/crop an image to fit it -- you can do that today with object-fit: https://codepen.io/eeeps/pen/KxapQy

The HTML intrinsicsize/CSS aspect-ratio use cases are more like -- you want to specify one (probably flexible) dimension (of an image, container, whatever) and have the other automatically calculated in relation to it based on a fixed aspect ratio.

[determin1st]

i mean, if, for example, the container should increase programmaticly in width (from 100px to 200px absolute, because computed styles are absolute) the method may be FLIP: https://aerotwist.com/blog/flip-your-animations/

in short, [F]irst, it takes starting width (100 - reading computed style), [L]last, determines ending width (200 - applying final style, reading computed style), [I]verts, removing final style, and [P]lays, using css translateX, changing it through time (animates). In the end, css transforms are removed and replaced with final style (it may be not absolute). EDIT: wrong, it sets the final width in [F]irst step, and removes only transofrms at the end. the link^

if the container has sub-containers with content, it will be stretched/morphed, as you see it happens with "A Kitten" text when the checkbox "use ExpoScale ease" is unset. The bad thing, that, to keep inner sub-container visually "correct", you have to counter-size it (reduce its translateX at some rate which has to be calculated) to some value which has to be calculated.

This only happens with transforms. If I use/animate only width property of the container (and have relative sizes of inner content) there will be no "visual bugs", but, it is considered, not smooth enough (Lots of rendering in browser performance debugger tool). So.. what you think, is it worth implementing transforms or maybe, they (browsers) will upgrade in the future, become more speedy (giving that to GPU) and eliminate the need to play with transforms?