[csswg-drafts] New CSS attribute proposal, expand: width height; (#6718)

alvaro-prieto has just created a new issue for https://github.com/w3c/csswg-drafts:

== New CSS attribute proposal, expand: width height; ==
I am not a native English speaker nor a CSS guru, so sorry for my  poor communication skills.

Please, first of all think of a big image (*lets say 2000x1000px*). Append it as a child of an inline-block container and as you would imagine, the inner image will push the bounds of its container trying to make it as big as possible until reaching 2000x1000 in a fixed ratio of 2:1. If either the image or its container has a max-width, let's say 1000px, its block axis will grow proportionally until reaching 500px.

I am missing the same kind of behavior for non-image elements, and this is why I'm proposing a new attribute ***"expand"*** or maybe ***“ratio”*** to increase the possibilities of what can be achieved with CSS.

Imagine another scenario using plain divs: **"center the biggest possible circle in an arbitrary sized rectangle"**. Easy, huh? Not so much using only HTML + CSS, I only achieved it using dummy image [as you can see in this example](https://codepen.io/alvaro-prieto/pen/abyowBe). Is there any non-hacky way to do it? I guess not, this is one of the reasons why a "expand" CSS attribute would be very useful.

This is a rough initial idea of ​​how this attribute might work. Expand could only be applied to elements that are not purely “inline”.

To get an element that behaves the same as a 2000x1000px image, my proposal is the following:
```
expand: 2000px 1000px;
```
With this syntax, we are indicating that an element wants to grow proportionally as long as it does not meet opposition until it reaches the size of 2000x1000px. If the element encounters an explicit size restriction (either by `width`, `height`, or their respective `max` and `min` in the element itself or any of its ancestors), its size will be limited according to the axis that imposes the restriction, and calculating the dimensions on the orthogonal axis using the known proportion.

In the case that the element trying to expand is a child of an adaptable container that has to calculate its size based on other competing sibling elements, as for example in the case of a `flex` container, its size could be calculated in the same way as an equivalent image would behave nowadays.

Another possible use of the “expand” attribute could be to explicitly indicate the “ideal“ or “desired” size for an element in one of its axes for elements that can be displayed in a wide range of sizes, so that it could be used as an “advise” or “suggestion“ for the algorithm in charge of distributing multiple elements in a limited space, for example using a `flex` container.

In this way, the following line would advise the corresponding layout algorithm to reserve a space of 300px for it on the block axis (only if possible).
```
expand: 300px auto;
```

This concept, in conjunction with container queries, can provide a lot of flexibility, since self-contained componentes (*that can be displayed in a wide range of sizes*), would now have a mechanism to show its size preference if they are added in a flex-wrap container, thus optimizing the number of elements per row to get closer to the desired natural size if possible.

So if we have “container-responsive” elements of class A and B in a `flex` container, and one of them prefer to be rendered at 300px width and the other at 100px width, the algorithm will be able to make its magic to fit them as good as possible according to their suggestion. The size proposal comes from the child, not from the parent. Of course any explicit rule in the parent container will have preference.

There are more cases that could be debated in reference to the fictitious attribute “expand”, for example using it with negative values, that is, an element that instead of trying to expand like a balloon filled with air, acts like an empty elastic balloon that tries to  “shrink” its content by reducing it in a fixed proportion if the two axes are established, or by crushing it only in one of the axes if the other acquires the “auto” value.

I could deepen and refine these ideas if they are considered of interest, but I prefer to publish this suggestion in a very early stage in case my proposal is far-fetched.

Please take a look at my Codepen to understand [the main purpose of this suggestion](https://codepen.io/alvaro-prieto/pen/abyowBe): to get rid of the “dummy” image element.

Regards, and thank you very much


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6718 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 8 October 2021 13:59:49 UTC