Re: [csswg-drafts] [css-ui] ? Allow <textarea> to be sized by contents. (#7542)

Thanks both @bfgeek and @clshortfuse! 

> Then discussion come about the complexities of making `<input>` multiline.

Yeah, that's not going to happen, but autosizing width is still very useful! I've written *a lot* of fragile custom code to facilitate this.

> We are bikeshedding the (current) `form-sizing` property, and the two values `auto` and `normal`.

Not sure if this is still on the table, but I would really, *really* prefer a value on `width` and `height` for this instead of a new property. Reasons:
* Conflicts: With a new property, it's unclear how it interacts with `width` and `height`.   How is`form-sizing: normal; height: 2lh;` supposed to behave? Does the height override the size-by-contents height? Does it function as a fallback for browsers that don't support `form-sizing` and do nothing in browsers that do? In general, we've seen time and time again that having features that disable other features is the root cause of a lot of author pain.
* Discoverability and learnability: Seeing something like `height: from-input` makes it clear that this is some kind of height sizing. Whereas `form-sizing` could be about anything that affects the control's box model (e.g. think of `box-sizing` which by naming sounds related). Even if it's clear that it's about adapting the control's dimensions to its content, is it adapting the width or the height? Not to mention it's conceivable to eventually want to allow both on the same control.
* Compat: The upgrade path to supporting `<input>` width autosizing is unclear. If this feature launches working only for `<textarea>` then it may not be web compatible to also allow it to work for `<input>`. So then what do we do? Introduce a separate property for input? And what about `<select>` even later? Another one? Yikes!
* A keyword on `width` or `height` allows future granularity, rather than generic terms like `normal`. E.g. if we wanted to expand this to `<select>`, does `normal` size by currently selected option or the option with the maximum size? These could be different keywords.

If this is entirely a non-starter for &lt;reasons>, the new property should at least make it clear what dimension is being altered (width/height/block/inline).

I also agree about the arguments against `legacy` as a value. Also, `legacy` implies this is not useful and only exists for legacy reasons, but there are *plenty* of use cases where you don't want to size form fields by their contents.

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


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

Received on Wednesday, 4 October 2023 19:44:52 UTC