- 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