Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
LeaVerou opened this issue Apr 16, 2024 · 1 comment
Open

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

LeaVerou opened this issue Apr 16, 2024 · 1 comment
Labels
css-ui-4 Current Work

Comments

@LeaVerou
Copy link
Member

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

@LeaVerou LeaVerou added the css-ui-4 Current Work label Apr 16, 2024
@tabatkins
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-ui-4 Current Work
Projects
None yet
Development

No branches or pull requests

2 participants