[csswg-drafts] [css-sizing] Possible to reproduce a `<div>`'s `width: auto` behavior on any element? (#7427)

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

== [css-sizing] Possible to reproduce a `<div>`'s `width: auto` behavior on any element? ==
Hello dear CSS Working Group people!

I spend a lot of time building UI components, and I always try to make them as flexible as possible, in the sense that they should adapt well to different contexts (and different contents, if they accept children), ideally on their own (i.e. with no changes to their HTML/CSS and without relying on any JS).

One reliable way that I've found to achieve that is to make components "responsive" or "fluid" by default, meaning that they should behave basically like a block element: their width should stretch to their parent's width, unless they are in a context that dictates their width or makes them "shrink-to-fit" to their intrinsic width, like if they are a Flexbox or Grid child, or the child of a `position: absolute` element that doesn't have a width. That is quite easy to do by making the root element of each component a `<div>` with no explicit `width` (so it uses the default value of `auto`), making it behave exactly as I just described.

That works, but in many cases, I would love the root element to be something other than `<div>`. For instance, if my component is a `<button>`, I haven't managed to reproduce the above behavior without a wrapper `<div>` (note: it doesn't have to be specifically a `<div>` – other block-level elements like `<section>` or even non-block elements like `<span>` with `display: block` on them work as well – but `<div>` makes the most sense semantically, since it's just a generic block container). That is because, unfortunately, `width: auto` doesn't have the same behavior on all elements, even with `display: block`; for instance, a `<button>` will "shrink-to-fit" its contents, as if it was `display: inline-block` or inside a Flex container or something (related issues: #3226, #6789). It's not just about `<button>` or (semi-)replaced elements, though: notably, `<table>` has the same problem.

I have tried all those new intrinsic sizing keywords for the `width` property (`min-content`, `max-content`, `fit-content`, and `stretch`), but none of them seem to do what I want, which is to reproduce the behavior that `auto` has for block-level elements such as `<div>`. I realize that the behavior I'm after is a mix between extrinsic and intrinsic sizing based on the context, but hopefully it makes sense to others.

`width: 100%` is also not an acceptable solution, as it doesn't behave the same as `auto` in a Flexbox or Grid context: instead of shrinking to fit, the component would always stretch to the container (or column's) width, or in the case of Flexbox, at least mess with the sizing algorithm (assuming `flex-basis: auto` + there are other flex items that don't wrap). Just to explain why I want the shrink-to-fit behavior, let's take the button example again. On a given page or screen size (e.g. mobile), maybe we want the button to be "full width" in its container (e.g. a sidebar), but on another page or screen size (e.g. desktop), maybe we want the same button component to be centered inside its container. With the shrink-to-fit behavior, that centered requirement becomes as simple as placing it in a `<div style="display: flex; justify-content: center;"></div>`. No need to change the button component itself; it adapts well to both contexts.

Again, I _do_ have a functional workaround, which is to wrap the `<button>` in a `<div>` inside the component, and then set `width: 100%` on the `<button>` itself (it still shrinks-to-fit when desired/expected, because the parent `<div>` does). However, I can't help but wonder if it would make sense to introduce a new keyword for `width` that would reproduce the `<div>`'s `width: auto` behavior for _any_ element, including `<button>`, `<input>`, `<table>`, etc. Maybe I missed something and it's already possible, in which case, please let me know. :)

Thank you for reading!

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


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

Received on Tuesday, 28 June 2022 20:55:23 UTC