You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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>.
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.
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 iffield-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 thanfield-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:
Instead, given the current implementation, it has to be:
Not a huge problem in the large scheme of things, but why not fix it while we still can :)
cc @frivoal @tkent-google
The text was updated successfully, but these errors were encountered: