Re: [csswg-drafts] [css-forms] Allow making <button> a real inline (or block/flex/etc) (#3226)

I recently created [a separate issue](https://github.com/w3c/csswg-drafts/issues/7427) about the impossibility to make some elements, including `button`, behave like a regular block element with no explicit width. But since 90% of the time, it's a `button` that I would like to see this for, I am going to repeat myself a little here.

I work on design systems / UI libraries, and in pretty much every library I've worked on, buttons are core components. And I always struggle with the same issue. I want my components to be flexible/responsive by default, meaning that when no explicit width is passed, I want them to adapt to their context: in block layout, they should stretch to fill their container's width (just like a `div` does), and in flex layout or other contexts (e.g. `position: absolute`), the shrink-to-fit algorithm should be used. Unfortunately, the only way I found to achieve that in a component that renders a `button` element is to render a `div` wrapper with no `width`, that contains a `button` element with a `width` of `100%`. I wish it was possible for a `button` to be sized like a regular block element (e.g. `div`), so that the wrapper would no longer be necessary. In the issue I mentioned above, @dbaron mentioned that `width: stretch` should do that, but after reading [[css-sizing-4] 6.1. Stretch-fit Sizing: filling the containing block](https://www.w3.org/TR/css-sizing-4/#stretch-fit-sizing), I don't think that's the case. Perhaps a solution could be a new keyword for `width` (I'm thinking `width: block`), but I am wondering if that's the right way to approach it or if the approaches proposed in this thread (i.e. `appearance: none` + `display: block`, or a new property altogether) would make more sense for this problem as well.

Thank you for reading. ❤️

-- 
GitHub Notification of comment by benface
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3226#issuecomment-1222926779 using your GitHub account


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

Received on Monday, 22 August 2022 20:17:59 UTC