

Chrome gets date and time pickers - taylorbuley
http://jsfiddle.net/taylorbuley/eDAmg/

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

~~~
bryanlarsen
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-...](http://blog.romanliutikov.com/coding/discover-the-dark-side-with-
shadow-dom/)

\-----

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

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

Thanks for the help.

~~~
pygy_
You're back!

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

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

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

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

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

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

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

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

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

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

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

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

------
devniel
<input type=color /> also works

------
sergiotapia
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...](http://lostinthegc.wordpress.com/2012/04/17/how-to-style-the-date-
html-input-type-using-css/)

------
AndrewHampton
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
For me the date picker appeared on my secondary monitor when the chrome window
was on my primary monitor.

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

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

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

------
mite-mitreski
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...](http://blog.mitemitreski.com/2012/10/input-this-input-that-
html5-new-input.html) When I was evaluating browsers for support it turned out
that Opera is most up to date when we talk about input and desktop.

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

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

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

------
mikegirouard
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
Here you go [https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-
Brow...](https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-
Polyfills)

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

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

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

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

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

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

------
alpb
iOS 6 Safari already has it.

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

------
tjholowaychuk
dear god it's ugly

------
maximem
really neat!

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

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

