5

I built a time mask in JavaScript which works great for PC's, Macs, iPhones, and iPads, but doesn't work consistently in most Android phones (I'd prefer not to get into the details of why this functionality can't work consistently in Android) so I disable it. For Samsung the built-in HTML5 time picker works great.

For Android phones I would like to leverage the HTML5 time pickers, when native browser time pickers are available (like for modern Samsung phones).

I know I can detect if the browser supports the date/datetime input types, but that doesn't necessarily indicate that the browser supports a time picker (For anyone who doubts this test it with an HTC EVO 3D, as just one example.) This Question ( Detect browser's native date/time pickers ) indicates that the if the time type is supported then the browser has implemented a time picker, but this is wrong.

I'm aware of modernizr but I don't see a way to actually verify if the browser supports a timepicker.

So with that background information. Does anyone know of a way to determine if the browser has implemented a time picker?

Community
  • 1
  • 1
SemanticZen
  • 1,141
  • 14
  • 21
  • What do you mean, _"actually verify if the browser supports a timepicker."_? That's exactly what modernizr does. – Cerbrus Dec 05 '12 at 07:54
  • Maybe try the same thing as suggested solution in the question you reference but try to set a date and read it as well? If date returned it should support the input type. – Rik Dec 05 '12 at 07:57
  • 1
    _"actually verify if the browser supports a timepicker"_ = Not just that the browser supports but that when the user clicks on a field it **pops up a time picker control** – SemanticZen Dec 05 '12 at 07:57
  • @Rik: As far as I know, if you set a `.value` on any input field, it will simply return that value when getting it, whether the input type is supported or not. [Fiddle example](http://fiddle.jshell.net/TahCz/). So, I don't think it's possible to check if the input actually "pops up a time picker control" – Cerbrus Dec 05 '12 at 08:07
  • @Cerbrus Ah I see, interestingly enough, Chrome does not return a value [Fiddle](http://fiddle.jshell.net/TahCz/2/) – Rik Dec 06 '12 at 12:38
  • @Rik: I see, yea. Well, that's one browser where you can apparently check it. – Cerbrus Dec 06 '12 at 12:48
  • 1
    Just one crazy idea: according to [this](http://stackoverflow.com/questions/16633057/is-it-possible-to-access-shadow-dom-elements-through-the-parent-document), there is no way to access the shadow dom elements inside a ``. But if it were possible, you could test the inner workings of the element to check if there is a date picker. Also, I've tried to use the vendor prefixed pseudoelements such as `-webkit-calendar-picker-indicator` to figure it out, but without success. Hope it helps. – rvidal Jun 05 '13 at 18:17

2 Answers2

2

I would argue that the safest bet is actually to assume that <input type="date"> is unsupported. As of today (early 2016), the actual UI for the date picker is still very inconsistent across browsers. Unless you're developing for a very concrete subset of browsers you are going to need some JavaScript anyway.

References:

rvidal
  • 2,012
  • 1
  • 17
  • 24
  • That is basically what I did. I use the type="date" across iOS devices and use a jQuery datapicker on all other devices – SemanticZen Jan 21 '16 at 21:57
0

Your best bet would be to assume that browsers that support a <input type="date"> have also implemented a time-picker for it.
(As far as I know, this is the case, what point would there be in supporting type="date", if it didn't have a reasonable way to input the date?)

This is because there's no way to check if the browser actually shows a timepicker. Aside from the modernizr checks, there's really nothing you can do.

Cerbrus
  • 70,800
  • 18
  • 132
  • 147
  • 3
    Unfortunately that is a bad assumption – SemanticZen Dec 05 '12 at 08:47
  • 2
    So, there are browsers that don't have a time-picker, even when supporting `date` inputs? I'm afraid you really have no other choice than to trust the browsers – Cerbrus Dec 05 '12 at 08:49
  • 1
    Unfortunately, that is the case. So the options seems to be 1. assume all Android phones do not support time-pickers or 2. detect each phone/carrier android device that does support time-picker (via user agent)... 2 bad options – SemanticZen Dec 05 '12 at 09:12
  • 1
    I'm afraid so. While this isn't really the answer you want, would you mind marking it as the answer, any way? (Sometimes, a "nope, that's not possible" is the correct answer, sadly.) – Cerbrus Dec 05 '12 at 09:18
  • If no better answer comes along this unfortunately will be the 'best' answer and I'll mark it as such. Let's wait a couple days... Hope springs eternal – SemanticZen Dec 05 '12 at 09:22