Chrome gets date and time pickers | Hacker News Reader

Chrome gets date and time pickers

jsfiddle.net

195 pointstaylorbuley63 comments

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.

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-...

I suspect you'd be able to style it using the shadow DOM.

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:

edit: styling a video tag example http://blog.romanliutikov.com/coding/discover-the-dark-side-...

-----

trying to figure out that myself. i mostly lurk, and have only ever commented a few times. not feeling very welcomed atm!

Since one can't reply to [dead] posts, I'll put this here.

crandles said: trying to figure out that myself. i mostly lurk, and have only ever commented a few times. not feeling very welcomed atm!

---

It's probably a false positive in an algorithm. I don't think that any human would have banned you, at least not based on what's visible in your history.

The only potentially problematic item is your first submission , the GMail April's fools joke that you posted on your very first day here. It's [dead]. What's surprising is the delay between the post and the ban...

Send a message to info@ycombinator.com, hopefully your account will be restored.

Yeah, that was some time ago, and I've had comments since then so its a little odd.

Thanks for the help.

You're back!

> As a web developer, I enthusiastically welcome native date and time pickers in web browsers...but boy are they ugly!

Agreed, the Chrome datepicker has been there for some time and is atrocious. I get a point for no styling: they can be made to feel native, e.g on iOS they're good but the Chrome ones simply are not.

> Without the ability to style them, this will not get widespread adoption. I am all for consistency in browser inputs

Indeed, but I see another advantage: what this will give us is UI<->data normalization, as third party pickers will have a tendency to converge towards the standard in terms of data handling so as to act properly as fallbacks to the standardized way.

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

Where Canary also has a special calendar that actually displays which week # it is: 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.

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.

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.

I think that's going to be problematic. I'm located on Spain but all my software is configured as en_US for convenience.

>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.

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, ...

don't forget: way too often you hit automated or really poor translations.

What's wrong with

LANG=es_ES LC_MESSAGES=en_US

(or GUI equivalent)?

The lack of a well-supported GUI equivalent.

> This is an HTML5 item, so it should eventually come to all browsers.

Though the date and time pickers which have been produced so far (outside of mobile phones maybe) are essentially garbage, in no small part for exactly the reason you suggest:

> Unfortunately, localization has not been properly addressed

which could even be extended to formatting in general. They also tend to look... bad. Not just "it's not a work of art" bad, but "this shit looks worse than most HTML/JS widgets created in the past 5 years and there is absolutely no hook anywhere to style them to match one's site"

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

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

> 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.

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.

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

I think it picks the operating system settings. "dd. mm. yyyy" for me on Chrome with non-US date-time settings in OS X.

Been in the US for a few years now, this format still drives me crazy :( It isn't logical at all

I've been in the US since birth and I write in the YYYY-MM-DD format on all documents.

I didn't start doing this till I started programming. It never occurred to me how much more logical this approach was till then.

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 :(

Well we had a standard for driving (galloping) along the road, then Hitler came...

effin' unified power plugs?

ISO has been created for you! the standard date is Y-M-D H:M:S

It shows dd/mm/yyyy for me - Chrome 23, Windows 7 set to en-AU locale.

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.

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.

<input type=color /> also works

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...

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

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

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.

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

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..

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-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.

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).

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

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.)

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.

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?

Here you go https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Brow...

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

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

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.

Probably because the HTML replacements for this suck more on Android

The week selector didn't work for me though. Nexus 7.

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

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

iOS 6 Safari already has it.

iOS 5.1.1 Safari also supports these.

Yes, but Android does not have them yet, and that is the place where it would really be useful.

dear god it's ugly

really neat!

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.

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.

Reply on news.ycombinator.com