9 ms·

Chrome gets date and time pickers

195 points by taylorbuley 14y ago

xbryanx 14y ago
Unfortunately it doesn't look like the internal elements of the date picker in the calendar respect my browser text-size settings. Along with the other styling comments here, I hope that we keep accessibility in mind and allow the user to control their font size for these UI elements. I hope this is just an oversight or my user-error.
zerostar07 14y ago
I would have liked to see an analog-clock time picker.
- bengl3rt 14y ago
  Don't worry, I'm sure Safari will have one (licensed from the Swiss Railway, of course) in short order.
rmc 14y ago
It seems to use the US locale, with it's "Month/Day/Year" for the date input. This is wrong (for me).
- dchest 14y ago
  I think it picks the operating system settings. "dd. mm. yyyy" for me on Chrome with non-US date-time settings in OS X.
- vijayr 14y ago
  Been in the US for a few years now, this format still drives me crazy :( It isn't logical at all
  - carbocation 14y ago
    I've been in the US since birth and I write in the YYYY-MM-DD format on all documents.
    - criswell 14y ago
      I didn't start doing this till I started programming. It never occurred to me how much more logical this approach was till then.
      - vijayr 14y ago
        Sometimes I wish we had standards for these across the world. One metric system (miles or km? please agree on one), standard set of traffic signs (without any text), just drive on one side of the road (left or right?) etc - obviously some of these aren't practical (like driving) but some are (like establishing uniform traffic/road signs without any text, just pictures). I know it is wishful thinking :(
        agilebyte 14y ago
        Well we had a standard for driving (galloping) along the road, then Hitler came...
        riffraff 14y ago
        effin' unified power plugs?
        gbog 14y ago
        ISO has been created for you! the standard date is Y-M-D H:M:S
- RossP 14y ago
  It shows dd/mm/yyyy for me - Chrome 23, Windows 7 set to en-AU locale.
- jebblue 14y ago
  Actually I agree, day/month/year would make more sense. Or year/month/day either way like we did it in the service makes more sense than month/day/year.
AndrewHampton 14y ago
Huh, the positioning of the date picker is on the primary monitor for me even when the chrome window is on the secondary monitor.
- arthulia 14y ago
  For me the date picker appeared on my secondary monitor when the chrome window was on my primary monitor.
bryanlarsen 14y ago
This is an HTML5 item, so it should eventually come to all browsers. Unfortunately, localization has not been properly addressed, in my opinion, so we're not going to be able to use it. Yes, theoretically people should choose their locale in their browser settings, but most people do it on a site-by-site basis.
- Adirael 14y ago
  I think that's going to be problematic. I'm located on Spain but all my software is configured as en_US for convenience.
  - jamoes 14y ago
    >I'm located on Spain but all my software is configured as en_US for convenience. Out of curiosity, why? I am always frustrated with Google (and others) for using my IP address to determine my locale setting, when I clearly have indicated en_US in the headers I send down to them. But I can see why they do if a lot of people purposefully don't set their locale correctly for whatever reason.
    - ward 14y ago
      I can't speak in grandparent's name, but as a Belgian doing the same thing my main reasons are: * Consistency 1. Most sites I spend my time on have English content. Same goes for programming, keywords are English, comments end up being English, etc. * Consistency 2. Not every program I use has a (complete) Dutch version. * Looks. Not everyone out there seems to take into account different languages when designing. Some English things cannot be said as shortly in Dutch without sounding silly (this works both ways). So pieces of the UI will look either overcrowded or overly empty. (Or the text sounds so odd because it got artificially shortened to fit) * Convenience 1. When looking up an explanation/details about some programs you are using, the info will almost always be in English. It is easier to use the same language to find back what you need. * Convenience 2. When reporting problems/bugs/finding out info about it, it is easier to use the English term used to find the info I need. Those are the main things coming to mind. It's not like I've ever had real trouble understanding English anyway, so it's not a bother to put everything in English. Keeping all that in mind, I do like my dates/times/... like I am used to them. Weeks start on Monday, times are in 24h clock, 16 Nov instead of Nov 16, 16/11/2012 instead of 11/16/2012, ...
blauwbilgorgel 14y ago
If you change your browser settings to use a different language, the date input will be localized to that language. I'd love to have a little more control over this. Perhaps adding: lang="fr" to the input element or even the <html> tag, could localize the input? The date picker runs from 01-01-0001 to 13-9-275760. Is this upper limit due to accuracy? DateComponents.h static inline double maximumDate() { return 8640000000000000.0; } // 275760-09-13T00:00Z
- ptgloden 14y ago
  Dates in JavaScript can represent 10^8 days from 1/1/1970 in either direction. For more, see: http://www.merlyn.demon.co.uk/js-datex.htm#RoND http://www.merlyn.demon.co.uk/js-datex.htm#RoND
- bnr 14y ago
  > I'd love to have a little more control over this. Perhaps adding: > lang="fr" No, please, don't! Leave the users in control, developers will just screw this up with country=language=locale logic.
  - ansgri 14y ago
    Then the browser localizes for you what it can and you'll get a very ugly-looking page that is almost all in e.g. French and dates in English. Seen that with some CMS which auto-localize their UI but not content, obviously.
maximem 14y ago
really neat!
simonsarris 14y ago
It's worth noting that these look very different even between Chrome Developer and Chrome Canary versions. They look like, respectively: http://i.imgur.com/lFcfv.png http://i.imgur.com/lFcfv.png Where Canary also has a special calendar that actually displays which week # it is: http://i.imgur.com/F1HAr.png http://i.imgur.com/F1HAr.png ---------------------- By the way if anyone is considering running Chrome's Beta or Developer channel, I highly suggest running Canary as well and using it as a default. Canary, the nightly, is actually much more stable than Beta/Developer, in that when something breaks in the Developer build it also breaks in the Canary build, but Canary is fixed in a day and Developer is fixed in 1-3 weeks.
- Kudos 14y ago
  While things break for a shorter period in Canary, they also break more frequently. In my experience when they break something badly in Beta, they push a fix outside of the scheduled releases.
rymith 14y ago
Date pickers have been there for quite a while now, they were there this spring. It's a real nuisance because the styling and several other requirements simply weren't ready when we were looking to implement them. Instead, we just reverted to text boxes with a date picker implementation in JS.
taylorbuley 14y ago
Interestingly, it's been Opera that's taken the lead on all the new UI input elements in the HTML5 spec. Love to see Chrome playing catch up for once.
yesimahuman 14y ago
The type="time" picker UX is pretty confusing. I don't think I'd want to show that to my users.
- pavel_lishin 14y ago
  I hate that it skips me over to the next 'subfield' as soon as I've entered something that looks remotely legitimate - or as soon as I fail to. (Try typing 66 into the minutes field.)
- Cowen 14y ago
  Also, for my specific usage on an internal tool, the fact that it doesn't allow sub-minute (or sub-second) input is pretty annoying.
cryptoz 14y ago
Chrome has had date and time pickers for a while on Android. Which is weird, as Chrome on Android is usually way behind Chrome on desktop.
- VMG 14y ago
  Probably because the HTML replacements for this suck more on Android
- hayksaakian 14y ago
  The week selector didn't work for me though. Nexus 7.
rplnt 14y ago
Now if only Google had used them on their page. Since the change to horizontal "menu" for Search Tools, the date picker doesn't work in Opera, although it supports date/time for a surprisingly (considering support for some other features) long time (two years).
alpb 14y ago
iOS 6 Safari already has it.
- Someone 14y ago
  iOS 5.1.1 Safari also supports these.
- speleding 14y ago
  Yes, but Android does not have them yet, and that is the place where it would really be useful.
zakshay 14y ago
Looks good. However to actually use it in a neat app, it better be stylable via css and support localization(Month-Day-Year etc), otherwise we'll have to resort to a JS option most of the time, like is the case with styled selects.
mikegirouard 14y ago
If often thought about making an HTML5 fallback library for browsers that don't support features like this, or to make up for lack of localization, or to clean up ugly/unusable implementations. Does such a project exist?
- Bjartr 14y ago
  Here you go https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Brow...
sergiotapia 14y ago
Opera has had this for a while now, fantastic that this is catching on. Imagine not needing some jQuery widget to choose dates and times PROPERLY. Wow, I can't wait! http://lostinthegc.wordpress.com/2012/04/17/how-to-style-the-date-html-input-type-using-css/ http://lostinthegc.wordpress.com/2012/04/17/how-to-style-the...
larrybolt 14y ago
I don't mind these html5 items coming to all browsers, but I hope it will become possible to style these to your own needs, with vendor-prefixes or something alike. Because if you have a dark site it does become really annoying to have a bright white datepicker popup. Of course you could also just ignore these input types and roll your own based on javascript but what's the use than of this sort of enhancements..
jbail 14y ago
As a web developer, I enthusiastically welcome native date and time pickers in web browsers...but boy are they ugly! Maybe you disagree and think they look great. So, let's both get what we want and I'll apply some custom styling to get the look I want on my site and you can do the same on your site. The only problem is that it doesn't appear that you can style these. You can style the input itself pretty well, but how do you style the resulting datepicker that it displays? Without the ability to style them, this will not get widespread adoption. I am all for consistency in browser inputs, but unfortunately, that isn't what designers and clients demand. That specific look and feel of the datepicker, with those blue colors, blacks and sharp corners just isn't going to cut it for a lot of people. I think we will eventually see full styling support for these datepickers. Until then, this is cool, but something I won't be able to use except maybe on a personal project. I know that if I slid this into a project, the first question I would get is, "Can we change the way it looks?" Maybe I just need to find less demanding clients.
- crandles 14y ago
  If its just a matter of styling, then there is a movement to make styling these sort of components as accessible as anything else on the web. Its still in spec, but you should take a look at the Shadow DOM. Not the most familiar with it, but I believe the gist of it is to allow developers to create self-contained widgets (or at least part of its usefulness). With it, you'll also be able to access/manipulate browser elements (they'll be presented with a Shadow DOM interface just like a custom widget). Think styling an HTML5 Video/Audio Player. Each browser may have their own interface, but they'll be built using components, and you'll have access to them using CSS/Javascript in your web page. With the Shadow DOM, you should be able to manipulate said datepicker. edit: styling a video tag example http://blog.romanliutikov.com/coding/discover-the-dark-side-with-shadow-dom/ http://blog.romanliutikov.com/coding/discover-the-dark-side-...
- ronaldj 14y ago
  I suspect you'd be able to style it using the shadow DOM.
- bryanlarsen 14y ago
  crandles is hell-banned, but posted what looks like a very relevant comment. [EDIT: he doesn't look hell-banned, I have no idea what is going on, since it doesn't appear to be a duplicate either] Pasting: If its just a matter of styling, then there is a movement to make styling these sort of components as accessible as anything else on the web. Its still in spec, but you should take a look at the Shadow DOM. Not the most familiar with it, but I believe the gist of it is to allow developers to create self-contained widgets (or at least part of its usefulness). With it, you'll also be able to access/manipulate browser elements (they'll be presented with a Shadow DOM interface just like a custom widget). Think styling an HTML5 Video/Audio Player. Each browser may have their own interface, but they'll be built using components, and you'll have access to them using CSS/Javascript in your web page. With the Shadow DOM, you should be able to manipulate said datepicker. edit: styling a video tag example http://blog.romanliutikov.com/coding/discover-the-dark-side-with-shadow-dom/ http://blog.romanliutikov.com/coding/discover-the-dark-side-... -----
devniel 14y ago
<input type=color /> also works
tjholowaychuk 14y ago
dear god it's ugly
y1426i 14y ago
You can customize these using shadow DOM. This thing is great.
jspaur 14y ago
anyone else able to get the seconds to work in the time picker? if not, why even show these?
topbanana 14y ago
Anything that reduces the chance of my ever again having to write one of these can only be a good thing.
deleted 14y ago
[deleted]
mite-mitreski 14y ago
This is great, I actually wrote a blog post some time ago about input types http://blog.mitemitreski.com/2012/10/input-this-input-that-html5-new-input.html http://blog.mitemitreski.com/2012/10/input-this-input-that-h... When I was evaluating browsers for support it turned out that Opera is most up to date when we talk about input and desktop.

195 points by taylorbuley 14y ago

Unfortunately it doesn't look like the internal elements of the date picker in the calendar respect my browser text-size settings. Along with the other styling comments here, I hope that we keep accessibility in mind and allow the user to control their font size for these UI elements. I hope this is just an oversight or my user-error.

zerostar07 14y ago

I would have liked to see an analog-clock time picker.

bengl3rt 14y ago
Don't worry, I'm sure Safari will have one (licensed from the Swiss Railway, of course) in short order.

rmc 14y ago

It seems to use the US locale, with it's "Month/Day/Year" for the date input. This is wrong (for me).

dchest 14y ago
I think it picks the operating system settings. "dd. mm. yyyy" for me on Chrome with non-US date-time settings in OS X.
vijayr 14y ago
Been in the US for a few years now, this format still drives me crazy :( It isn't logical at all
- carbocation 14y ago
  I've been in the US since birth and I write in the YYYY-MM-DD format on all documents.
  - criswell 14y ago
    I didn't start doing this till I started programming. It never occurred to me how much more logical this approach was till then.
    - vijayr 14y ago
      Sometimes I wish we had standards for these across the world. One metric system (miles or km? please agree on one), standard set of traffic signs (without any text), just drive on one side of the road (left or right?) etc - obviously some of these aren't practical (like driving) but some are (like establishing uniform traffic/road signs without any text, just pictures). I know it is wishful thinking :(
      - agilebyte 14y ago
        Well we had a standard for driving (galloping) along the road, then Hitler came...
      - riffraff 14y ago
        effin' unified power plugs?
      - gbog 14y ago
        ISO has been created for you! the standard date is Y-M-D H:M:S
RossP 14y ago
It shows dd/mm/yyyy for me - Chrome 23, Windows 7 set to en-AU locale.
jebblue 14y ago
Actually I agree, day/month/year would make more sense. Or year/month/day either way like we did it in the service makes more sense than month/day/year.

AndrewHampton 14y ago

Huh, the positioning of the date picker is on the primary monitor for me even when the chrome window is on the secondary monitor.

arthulia 14y ago
For me the date picker appeared on my secondary monitor when the chrome window was on my primary monitor.

bryanlarsen 14y ago

This is an HTML5 item, so it should eventually come to all browsers. Unfortunately, localization has not been properly addressed, in my opinion, so we're not going to be able to use it. Yes, theoretically people should choose their locale in their browser settings, but most people do it on a site-by-site basis.

Adirael 14y ago
I think that's going to be problematic. I'm located on Spain but all my software is configured as en_US for convenience.
- jamoes 14y ago
  >I'm located on Spain but all my software is configured as en_US for convenience. Out of curiosity, why? I am always frustrated with Google (and others) for using my IP address to determine my locale setting, when I clearly have indicated en_US in the headers I send down to them. But I can see why they do if a lot of people purposefully don't set their locale correctly for whatever reason.
  - ward 14y ago
    I can't speak in grandparent's name, but as a Belgian doing the same thing my main reasons are: * Consistency 1. Most sites I spend my time on have English content. Same goes for programming, keywords are English, comments end up being English, etc. * Consistency 2. Not every program I use has a (complete) Dutch version. * Looks. Not everyone out there seems to take into account different languages when designing. Some English things cannot be said as shortly in Dutch without sounding silly (this works both ways). So pieces of the UI will look either overcrowded or overly empty. (Or the text sounds so odd because it got artificially shortened to fit) * Convenience 1. When looking up an explanation/details about some programs you are using, the info will almost always be in English. It is easier to use the same language to find back what you need. * Convenience 2. When reporting problems/bugs/finding out info about it, it is easier to use the English term used to find the info I need. Those are the main things coming to mind. It's not like I've ever had real trouble understanding English anyway, so it's not a bother to put everything in English. Keeping all that in mind, I do like my dates/times/... like I am used to them. Weeks start on Monday, times are in 24h clock, 16 Nov instead of Nov 16, 16/11/2012 instead of 11/16/2012, ...

blauwbilgorgel 14y ago

If you change your browser settings to use a different language, the date input will be localized to that language. I'd love to have a little more control over this. Perhaps adding: lang="fr" to the input element or even the <html> tag, could localize the input? The date picker runs from 01-01-0001 to 13-9-275760. Is this upper limit due to accuracy? DateComponents.h static inline double maximumDate() { return 8640000000000000.0; } // 275760-09-13T00:00Z

ptgloden 14y ago
Dates in JavaScript can represent 10^8 days from 1/1/1970 in either direction. For more, see: http://www.merlyn.demon.co.uk/js-datex.htm#RoND http://www.merlyn.demon.co.uk/js-datex.htm#RoND
bnr 14y ago
> I'd love to have a little more control over this. Perhaps adding: > lang="fr" No, please, don't! Leave the users in control, developers will just screw this up with country=language=locale logic.
- ansgri 14y ago
  Then the browser localizes for you what it can and you'll get a very ugly-looking page that is almost all in e.g. French and dates in English. Seen that with some CMS which auto-localize their UI but not content, obviously.

maximem 14y ago

really neat!

simonsarris 14y ago

It's worth noting that these look very different even between Chrome Developer and Chrome Canary versions. They look like, respectively: http://i.imgur.com/lFcfv.png http://i.imgur.com/lFcfv.png Where Canary also has a special calendar that actually displays which week # it is: http://i.imgur.com/F1HAr.png http://i.imgur.com/F1HAr.png ---------------------- By the way if anyone is considering running Chrome's Beta or Developer channel, I highly suggest running Canary as well and using it as a default. Canary, the nightly, is actually much more stable than Beta/Developer, in that when something breaks in the Developer build it also breaks in the Canary build, but Canary is fixed in a day and Developer is fixed in 1-3 weeks.

Kudos 14y ago
While things break for a shorter period in Canary, they also break more frequently. In my experience when they break something badly in Beta, they push a fix outside of the scheduled releases.

rymith 14y ago

Date pickers have been there for quite a while now, they were there this spring. It's a real nuisance because the styling and several other requirements simply weren't ready when we were looking to implement them. Instead, we just reverted to text boxes with a date picker implementation in JS.

taylorbuley 14y ago

Interestingly, it's been Opera that's taken the lead on all the new UI input elements in the HTML5 spec. Love to see Chrome playing catch up for once.

yesimahuman 14y ago

The type="time" picker UX is pretty confusing. I don't think I'd want to show that to my users.

pavel_lishin 14y ago
I hate that it skips me over to the next 'subfield' as soon as I've entered something that looks remotely legitimate - or as soon as I fail to. (Try typing 66 into the minutes field.)
Cowen 14y ago
Also, for my specific usage on an internal tool, the fact that it doesn't allow sub-minute (or sub-second) input is pretty annoying.

cryptoz 14y ago

Chrome has had date and time pickers for a while on Android. Which is weird, as Chrome on Android is usually way behind Chrome on desktop.

VMG 14y ago
Probably because the HTML replacements for this suck more on Android
hayksaakian 14y ago
The week selector didn't work for me though. Nexus 7.

rplnt 14y ago

Now if only Google had used them on their page. Since the change to horizontal "menu" for Search Tools, the date picker doesn't work in Opera, although it supports date/time for a surprisingly (considering support for some other features) long time (two years).

alpb 14y ago

iOS 6 Safari already has it.

Someone 14y ago
iOS 5.1.1 Safari also supports these.
speleding 14y ago
Yes, but Android does not have them yet, and that is the place where it would really be useful.

zakshay 14y ago

Looks good. However to actually use it in a neat app, it better be stylable via css and support localization(Month-Day-Year etc), otherwise we'll have to resort to a JS option most of the time, like is the case with styled selects.

mikegirouard 14y ago

If often thought about making an HTML5 fallback library for browsers that don't support features like this, or to make up for lack of localization, or to clean up ugly/unusable implementations. Does such a project exist?

Bjartr 14y ago
Here you go https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Brow...

sergiotapia 14y ago

Opera has had this for a while now, fantastic that this is catching on. Imagine not needing some jQuery widget to choose dates and times PROPERLY. Wow, I can't wait! http://lostinthegc.wordpress.com/2012/04/17/how-to-style-the-date-html-input-type-using-css/ http://lostinthegc.wordpress.com/2012/04/17/how-to-style-the...

larrybolt 14y ago

I don't mind these html5 items coming to all browsers, but I hope it will become possible to style these to your own needs, with vendor-prefixes or something alike. Because if you have a dark site it does become really annoying to have a bright white datepicker popup. Of course you could also just ignore these input types and roll your own based on javascript but what's the use than of this sort of enhancements..

jbail 14y ago

As a web developer, I enthusiastically welcome native date and time pickers in web browsers...but boy are they ugly! Maybe you disagree and think they look great. So, let's both get what we want and I'll apply some custom styling to get the look I want on my site and you can do the same on your site. The only problem is that it doesn't appear that you can style these. You can style the input itself pretty well, but how do you style the resulting datepicker that it displays? Without the ability to style them, this will not get widespread adoption. I am all for consistency in browser inputs, but unfortunately, that isn't what designers and clients demand. That specific look and feel of the datepicker, with those blue colors, blacks and sharp corners just isn't going to cut it for a lot of people. I think we will eventually see full styling support for these datepickers. Until then, this is cool, but something I won't be able to use except maybe on a personal project. I know that if I slid this into a project, the first question I would get is, "Can we change the way it looks?" Maybe I just need to find less demanding clients.

crandles 14y ago
If its just a matter of styling, then there is a movement to make styling these sort of components as accessible as anything else on the web. Its still in spec, but you should take a look at the Shadow DOM. Not the most familiar with it, but I believe the gist of it is to allow developers to create self-contained widgets (or at least part of its usefulness). With it, you'll also be able to access/manipulate browser elements (they'll be presented with a Shadow DOM interface just like a custom widget). Think styling an HTML5 Video/Audio Player. Each browser may have their own interface, but they'll be built using components, and you'll have access to them using CSS/Javascript in your web page. With the Shadow DOM, you should be able to manipulate said datepicker. edit: styling a video tag example http://blog.romanliutikov.com/coding/discover-the-dark-side-with-shadow-dom/ http://blog.romanliutikov.com/coding/discover-the-dark-side-...
ronaldj 14y ago
I suspect you'd be able to style it using the shadow DOM.
bryanlarsen 14y ago
crandles is hell-banned, but posted what looks like a very relevant comment. [EDIT: he doesn't look hell-banned, I have no idea what is going on, since it doesn't appear to be a duplicate either] Pasting: If its just a matter of styling, then there is a movement to make styling these sort of components as accessible as anything else on the web. Its still in spec, but you should take a look at the Shadow DOM. Not the most familiar with it, but I believe the gist of it is to allow developers to create self-contained widgets (or at least part of its usefulness). With it, you'll also be able to access/manipulate browser elements (they'll be presented with a Shadow DOM interface just like a custom widget). Think styling an HTML5 Video/Audio Player. Each browser may have their own interface, but they'll be built using components, and you'll have access to them using CSS/Javascript in your web page. With the Shadow DOM, you should be able to manipulate said datepicker. edit: styling a video tag example http://blog.romanliutikov.com/coding/discover-the-dark-side-with-shadow-dom/ http://blog.romanliutikov.com/coding/discover-the-dark-side-... -----

devniel 14y ago

<input type=color /> also works

tjholowaychuk 14y ago

dear god it's ugly

y1426i 14y ago

You can customize these using shadow DOM. This thing is great.

jspaur 14y ago

anyone else able to get the seconds to work in the time picker? if not, why even show these?

topbanana 14y ago

Anything that reduces the chance of my ever again having to write one of these can only be a good thing.

deleted 14y ago

[deleted]

mite-mitreski 14y ago

This is great, I actually wrote a blog post some time ago about input types http://blog.mitemitreski.com/2012/10/input-this-input-that-html5-new-input.html http://blog.mitemitreski.com/2012/10/input-this-input-that-h... When I was evaluating browsers for support it turned out that Opera is most up to date when we talk about input and desktop.