[css-ui-4] Interaction between `field-sizing` and `width`/`height`

[LeaVerou]

Spec: https://drafts.csswg.org/css-ui-4/#field-sizing
Relevant issues: #7552 #7542
Shipped status (currently only Chrome 123+): https://caniuse.com/mdn-css_properties_field-sizing

The spec is currently unclear on what happens if there are author-set dimensions AND field-sizing on the same element.
What Chrome has implemented is that if explicit dimensions are set, they seem to override field-sizing. I think that’s a mistake, as it necessitates excessive use of @supports for common things. The author intent if field-sizing: content is set seems clear, and I cannot think of any use case where one would want to return to fixed sizing by setting a width (rather than field-sizing: fixed). I'd argue it's far more common to specify a width/height as a fallback, especially for elements where the default UA styles are particularly unwieldy, such as <input type=number>.

It could be as simple as:

input[type=number] {
	width: 4ch;
}

.demo {
	input, select {
		field-sizing: content;
	}
}

Instead, given the current implementation, it has to be:

input[type=number] {
	width: 4ch;
}

.demo {
	input, select {
		@supports (field-sizing: content) {
			field-sizing: content;
			width: auto;
		}
	}
}

Not a huge problem in the large scheme of things, but why not fix it while we still can :)

cc @frivoal @tkent-google

[tabatkins]

The spec seems completely clear to me, and gives the behavior I'd expect - field-sizing changes how the element computes its intrinsic size, and setting an explicit width makes the element not care about its intrinsic width. (It still pays attention to the intrinsic height.) This works the same as every other element; the only difference between a field-sizing:content input and a div is that width: auto is max-content for the former and stretch for the latter.

Note that textarea { width: 100px; field-sizing: content; } sets a fixed width but makes the height still respond to content (wrapped at that width). It would be extremely bad if that was impossible.

[danburzo]

The fixed-width textarea is a more compelling argument, but I wanted to note that field-sizing also interacts with explicit dimensions via the resize property, which applies the user gesture as width / height properties. I think it’s beneficial to allow the user to override the dimensions of auto-sized fields, even if browsers don’t currently provide a way to unset these from the UI.