input type="date" in Safari renders an input much taller than others. Why not let it render like other inputs? The reasons are unknown. Luckily, it can be fixed by targeting the -webkit-datetime-edit pseudo-element.
There seems to be a couple of extra px of padding and a custom line height or a line height that isn’t given the same value as the other inputs.
The fix #
input::-webkit-datetime-edit {
line-height: 1;
padding: 0;
margin-bottom: -2px;
}
We could have slapped height on it, but I generally want to avoid setting that on elements. It forces content into shapes instead of letting content rule the sizing. It would also look weird because it messes up the padding inside the input.
No other browser needed the same when I tested this. In cases like this, I think it’s better to have a fix targetting that one browser instead of force-writing CSS into bloatedness. That way, it’s easier to know that the original class is safe to edit and the custom reset can be removed if Safari gets fixed.
I haven’t tested every input type in Safari, but I’m guessing similar types have the same issues.
Not the new IE #
Some say Safari is the new IE; in terms of being the one we now have to test extensively and target specifically, I agree. But it has better support for modern CSS than IE, the fixes are not as hacky, and Safari is in active development.