Temporal inputs are 2px taller than other textual inputs in Chrome

[cvrebert]

In Chrome, <input class="form-control">s with a type of datetime-local, date, month, week, or time are 40px tall, but <input type="text" class="form-control"> (and similar) are 38px tall. They ought to all match.
Looks like the temporal inputs use Flexbox internally; that's likely a factor.

[cvrebert]

To be clear, this is NOT causally related to #17308.

[alex321]

Is there any update on this?

[cvrebert]

@alex321 https://twitter.com/slicknet/status/782274190451671040

[malikfaizanhaider]

Same here !!!!!

On Oct 31, 2016 9:49 PM, "Chris Rebert" [email protected] wrote:

@alex321 https://github.com/alex321 https://twitter.com/slicknet/
status/782274190451671040

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#18842 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEeuOi8lGVdUffVn56By4CPREt7SzodFks5q5hwigaJpZM4HCLGQ
.

[gijsbotje]

can't find the temporal input types in the new docs except for the reboot page
so is this stil an issue?

[patrickhlauke]

yes, issue is still present for date, time, datetime-local, month and week in both Chrome and Edge (possibly others on MacOS and mobile, not tested). this is due to browsers' user agent stylesheet assigning subtly different padding/margin to these types of inputs. may explore if these can be somehow normalised. [edit: actually, not padding/margin - turns out it's the actual height of the inputs that's somehow set, possibly internally outside of the user agent stylesheet itself]

(and as an aside, <input type="color"> and <input type="range"> are of course totally bonkers)

[patrickhlauke]

turns out that only giving all inputs an explicit height (e.g. height:2.4rem for the regular sized inputs) can guarantee that the temporal inputs are the same height as non-temporal ones. which is a pain since this will then need to be done for small and large variants as well, and it subtly changes the overall vertical spacing and alignment of the user-entered value etc.

[langdonx]

Relevant: https://bugs.chromium.org/p/chromium/issues/detail?id=417606

It's unfortunately WontFix (and very old), but there's a solution:

::-webkit-inner-spin-button { display: none; }

It's a terrible solution on its own when you think about how critical that spinner is for input[type="number"], but when you target the inputs where it's not quite as helpful, it turns out to be pretty great:

input[type="date"],
input[type="datetime-local"],
input[type="time"],
input[type="month"],
input[type="week"] {
  &::-webkit-inner-spin-button {
    display: none;
  }
}

Before - http://jsbin.com/kigayoyeja/1/edit?html,css,output
After - http://jsbin.com/hifamocuwi/1/edit?html,css,output

Did I miss any input types?

[martincarlin87]

inline css isn't great but I've done this incase it's any use to anyone:

input[type="date"],
input[type="datetime-local"],
input[type="time"],
input[type="month"],
input[type="week"] {
    height: 38px;
}