-
-
Notifications
You must be signed in to change notification settings - Fork 78.9k
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
Remove explicit heights on form elements #31993
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hell. Yes.
a2a9dc0
to
5dc13b2
Compare
Don't merge this yet, I'm doing some tests withs input field heights to confirm this works (already found a bug in the current implementation which was solved in this PR, lol) |
5dc13b2
to
2e947f1
Compare
Ok, I made a codepen to check browsers with and it looks like we're ok with this change: https://codepen.io/MartijnCuppens/pen/JjKpbGd?editors=1010 I actually even found out there's a bug with the current implementation: https://codepen.io/MartijnCuppens/pen/PozQbqJ?editors=1010 |
i think this change now made |
Input heights were initially added in #26820 to fix #18842. Select heights were added to fix https://bugzilla.mozilla.org/show_bug.cgi?id=1560824.
But:
However, removing the explicit height would reintroduce #23307. Luckily, date inputs have a
::-webkit-datetime-edit
of which we can set the height inem
🎉This means, we can safely remove those (min-)heights that seem to cause some issues like #26820 (comment) or #31955 (comment) (this fixes issues when zoomed in/out)
I've kept a min-height for textareas, to keep support for #29124
I didn't apply this change to
.form-file
, since this will introduce conflicts with #31955, therefor I'll keep this in draft.