Why has the behavior of `input type="date"` changed?

Question

Date inputs such as <input type="date" name="due_date" id="due_date" min="2011-09-01" maxlength="10" class="span8"> in Chrome used to allow the user to see a "pop-up" calendar to help choose a date. I noticed yesterday that behavior has stopped; the input only allows the user to arrow up/down the date parts (month/day/year). I visited the Chrome blog and ran a Google search, but can't find any mention of this change. Why has the behavior of input type="date" changed? Curiously, this change seems to be limited to Bootstrap, as http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_input_type_date still exhibits the datepicker.

Have created a JSFiddle using the Bootstrap CSS and doesn't seem to affect Chrome's popup - http://jsfiddle.net/BxVDx/3/ — Kasaku, Feb 25 '13 at 15:49
I just confirmed this is a Bootstrap issue by going to Bootstrap's documentation and "inserting" `Choose date` into the default form example at http://twitter.github.com/bootstrap/base-css.html#forms. — Jeromy French, Feb 25 '13 at 15:50
@PirateKitten: I *do* see this problem in your fiddle. I'm using Chrome....Version 25.0.1364.97 m. You? — Jeromy French, Feb 25 '13 at 15:52
Yep just confirmed that my Chrome was slightly out of date, have updated and now seeing as you describe, so Chrome behaviour has changed as you thought. Sorry, I lost what version I was on so I can't quote it. — Kasaku, Feb 25 '13 at 15:55
Opened Bootstrap ticket: https://github.com/twitter/bootstrap/issues/7061 — Jeromy French, Feb 25 '13 at 15:59
After a long gap of seven years (or so it seems), the Google **Engineers** have done it again. Amid Covid-19 they decided to **roll out** their latest gem (ver. 83.0.4103.61) and all hell has broken loose. My app which looked good just the last time I visited it, looks all crappy now thanks to the mandarins at Google. [link](https://support.google.com/chrome/thread/48070162?hl=en). NOT only the date widget but input boxes as well have started to look funny. **In case somebody has come across the same problem, may please suggest a remedy**. — Love Putin Not War, May 30 '20 at 19:07
In the end it turned out to be a "design" by choice for the Google team [as they decided to overhaul the "look and feel" of the form controls](https://developers.google.com/web/updates/2020/05/nic83). But they did not leave the choice to us. — Love Putin Not War, May 31 '20 at 04:18

score 15 · Accepted Answer · edited Feb 28 '13 at 14:57

Update Chromium team accepted the bug and submitted a patch back to WebKit. The gist of the change is that the date controls will be rendered inside a flexible box element regardless of the style applied to the input[type='date'] control.

I'm the one that reported the defect referenced here to Chromium. One proposed solution is to apply display: inline-block; to the calendar picker:

input[type="date"]::-webkit-calendar-picker-indicator{
    display:inline-block;
}

However, that is a wonky solution because the controls are still shifted to a location other than right-justified on the input[type="date"] control.

Another option is to float right:

input[type="date"]::-webkit-calendar-picker-indicator {
    display:inline-block;
    margin-top:2%;
    float:right;
}
input[type="date"]::-webkit-inner-spin-button {
    display:inline-block;
    float:right;
}

This has the side-effect of inverting the spinner and calendar picker controls.

The best hack, I think is to remove the spinner and float right:

input[type="date"]::-webkit-calendar-picker-indicator{
    display:inline-block;
    margin-top:2%;
    float:right;
}
input[type="date"]::-webkit-inner-spin-button {
    /* display: none; <- Crashes Chrome on hover */
    -webkit-appearance: none;
    margin: 0;
}

chrome 25 input[type="date"] defect hack-arounds

Note that if you're floating an element, its display is set to `block`, so there's no point trying to set it to anything else. See [this CSS Tricks article](http://css-tricks.com/implied-block/), or just take a look at the computed style in Chrome dev tools. Speaking of those tools, people may not be aware that you can go to Settings>Elements>Show Shadow DOM to see the elements (`-webkit-inner-spin-button` etc) referenced in this answer. — CherryFlavourPez, Feb 28 '13 at 09:56
Chrome version 26.0.1410.43 m displays everything correctly again. — Jeromy French, Apr 01 '13 at 21:33

Karl Doyle · Answer 2 · 2013-02-26T19:07:32.230

6

updated

Found Problem

Bootstrap uses 2 style attributes..

1 - display:inline-block which makes google break the arrow onto another line

2 - height: 20px which prevents you from seeing this "line"

screenshot of findings

edited Feb 26 '13 at 19:07

answered Feb 25 '13 at 21:27

Karl Doyle

642
3
10

I see similar changes when I disable the `padding`. – Jeromy French Feb 26 '13 at 01:29

ximi · Answer 3 · 2013-02-27T07:16:19.787

2

Update

The Google Chrome Issue was marked as a regression, so this will hopefully be fixed soon. As a temporary workaround, the following will work:

input[type=date]::-webkit-calendar-picker-indicator {
    display: inline-block;
}

This way you can keep the inputs display property set to whatever you like and everything works as it did before.

Original Response

Setting display: -webkit-inline-flex (which seems to be the default for <input type="date" />) will fix this issue, this might however alter the layout, as the input is treated like an inline element.

This seems like a bug to me, I'll look if someone already filed a bug report, otherwise I will.

edited Feb 27 '13 at 07:16

answered Feb 26 '13 at 05:24

ximi

596
5
17

1

There is an issue in the chromium bugtracker, feel free to star it to get notified when there is an update and to express your interest in this getting resolved: https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=date%20picker&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20OS%20Area%20Feature%20Status%20Owner%20Summary&groupby=&sort=&id=178175 – ximi Feb 26 '13 at 07:50
Refer to my previous comment :) – Karl Doyle Feb 26 '13 at 08:14
Thanks @ximi. I also opened a Bootstrap ticket: http://github.com/twitter/bootstrap/issues/7061 – Jeromy French Feb 26 '13 at 14:58
@KarlDoyle, removing the property and resetting it aren't necessarily the same. – ximi Feb 26 '13 at 16:12
@JeromyFrench I'm not sure if the bootstrap guys will fix it, as there isn't really anything wrong with their code, but with chrome's implementation. I just hope the google guys will fix it – ximi Feb 26 '13 at 16:14
@ximi - true, I see that inline-block doesn't actually remove the arrow put drops it below the input, which you cannot see in bootstrap because the **height:20px** – Karl Doyle Feb 26 '13 at 19:03

Why has the behavior of `input type="date"` changed?

3 Answers3

Linked