- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 16 Apr 2024 16:02:52 +0000
- To: public-css-archive@w3.org
LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-ui-4] Interaction between `field-sizing` and `width`/`height` ==
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:
```css
input[type=number] {
width: 4ch;
}
.demo {
input, select {
field-sizing: content;
}
}
```
Instead, given the current implementation, it has to be:
```css
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
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10217 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 16 April 2024 16:02:55 UTC