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.

Sign up for GitHub

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

Jump to bottom

HTML inputs have different compressibility behavior depending on internal implementation details #6347

Open
tabatkins opened this issue Jun 3, 2021 · 0 comments
Open

HTML inputs have different compressibility behavior depending on internal implementation details #6347

tabatkins opened this issue Jun 3, 2021 · 0 comments
Labels
css-sizing-3 Current Work Target Revision: Next Remove when done.

Comments

@tabatkins
Copy link
Member

See the following testcase:

<!DOCTYPE html>
<style>
.flexbox {
 width: 50px;
 border: thin dotted;
 display: flex;
}
.test {
 width: 100px;
}
</style>

<div class=flexbox>
 <input class=test>
</div>
<div class=flexbox>
 <input class=test type=date>
</div>

Browsers consistently treat these two inputs differently: the text input stays at 100px wide, overflowing its flexbox parent, while the date input compresses to the available space and doesn't overflow.

In discussion with implementors, this is due to differences in internal implementations and default UA styles:

  • the text input contains a (100px wide) internal box to actually receive the textual input, so the input's automatic minimum size is 100px
  • the date input has a similar internal structure, but also has overflow:hidden set directly on it by the UA stylesheet (rather than on one of the internal bits, as for the text input), so its automatic minimum size is 0 due to it being a scrollable box.

Other input types have a similar split in behavior depending on how they're implemented internally. This is pretty confusing for authors! There's nothing about the elements that suggests they should have such divergent behavior, and it means authors can't predict how their input elements will work, even when they appear to be very similar types.

This divergent internal structure also probably contributes to our confusion about how compressible elements work in the Sizing spec...
@tabatkins tabatkins added the css-sizing-3 Current Work label Jun 3, 2021
@fantasai fantasai added the Target Revision: Next Remove when done. label Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-sizing-3 Current Work Target Revision: Next Remove when done.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tabatkins @fantasai