4 ms·

UI components might be hard, but typing <input type="date"> into a HTML document is not hard, and it's enough for the browser to do the right thing here. This

UI components might be hard, but typing <input type="date"> into a HTML document is not hard, and it's enough for the browser to do the right thing here. This screwup was entirely self-inflicted, a consequence of ignoring the well-known best practices of authoring semantically-meaningful web documents, forms and apps.

tlb 8y ago
That's currently only supported by 86% of browsers. A few years ago when they might have designed it, that number as much lower. See https://caniuse.com/#feat=input-datetime https://caniuse.com/#feat=input-datetime
Semaphor 8y ago
Regarding input type="date" > Recommendation > While convenient where it works, the failure mode of type="date" and its associated date and time types is very poor. This makes it a risky choice that could leave users struggling to meet validation criteria. [0]: https://www.smashingmagazine.com/2019/01/html5-input-types/#a8 https://www.smashingmagazine.com/2019/01/html5-input-types/#...
- mediumdeviation 8y ago
  I remember desktop Chrome ‘implementing’ date input a few years ago by using the number input’s spinner. If you press up the date goes to 0000-01-01. It was worse than useless because you can’t even polyfill in a JS datepicker since the usual feature detection would detect Chrome as having support for date input.
Sharlin 8y ago
For better or worse, 99.9% of the web uses custom datepickers, if not for other reason than the fact that <input type=date> is not supported by all the browsers out there.
cronos8989 8y ago
Sometimes the client want different look and behaviour for componet, not Just the simple HTML5 input
- jstanley 8y ago
  As evidenced by this example: in such cases, the client is probably wrong. They'd be better off letting the user agent display the date picker that the user is used to.
  - hn_throwaway_99 8y ago
    Don't conflate the simple fact that there is an outright bug here with the presumption that the browser's date picker would be a better choice.
    - jstanley 8y ago
      Even in the event that a browser ships a buggy date picker, at least it would be buggy on every website. The user then has a chance of understanding the bug and working around it to input the correct date.
      - hn_throwaway_99 8y ago
        OK, I'll use another tactic. Show me a single high-traffic travel website that uses the browser's default date picker. Travel websites are usually optimized out the wazoo because small increases in conversion rates make all the difference in this competitive business. Are you saying all those sites (the ones without bugs) are wrong?
    - YawningAngel 8y ago
      The user is responsible for their browser. If they choose to use something that doesn't implement the spec and your site breaks, they sabotaged their own experience. That's very different to you sabotaging their experience.
hn_throwaway_99 8y ago
If it's a "best-practice", I honestly don't know any large, consumer-facing websites that just use input type=date, mainly because that UI sucks in most cases. Even in this case putting the dollar amounts in the dates, which is a very useful piece of information, would need a custom date control.
Splines 8y ago
Is that even a web browser? If you look at the full screenshot, (I'm not 100% familiar with iOS) it looks like an app launched from the app store?
- saagarjha 8y ago
  That’s almost certainly an app; a web app would require quite a bit of configuration to look like that. It might be running a web view internally, though.
deleted 8y ago
[deleted]

tlb 8y ago

That's currently only supported by 86% of browsers. A few years ago when they might have designed it, that number as much lower. See https://caniuse.com/#feat=input-datetime https://caniuse.com/#feat=input-datetime

Semaphor 8y ago

Regarding input type="date" > Recommendation > While convenient where it works, the failure mode of type="date" and its associated date and time types is very poor. This makes it a risky choice that could leave users struggling to meet validation criteria. [0]: https://www.smashingmagazine.com/2019/01/html5-input-types/#a8 https://www.smashingmagazine.com/2019/01/html5-input-types/#...

mediumdeviation 8y ago
I remember desktop Chrome ‘implementing’ date input a few years ago by using the number input’s spinner. If you press up the date goes to 0000-01-01. It was worse than useless because you can’t even polyfill in a JS datepicker since the usual feature detection would detect Chrome as having support for date input.

Sharlin 8y ago

For better or worse, 99.9% of the web uses custom datepickers, if not for other reason than the fact that <input type=date> is not supported by all the browsers out there.

cronos8989 8y ago

Sometimes the client want different look and behaviour for componet, not Just the simple HTML5 input

jstanley 8y ago
As evidenced by this example: in such cases, the client is probably wrong. They'd be better off letting the user agent display the date picker that the user is used to.
- hn_throwaway_99 8y ago
  Don't conflate the simple fact that there is an outright bug here with the presumption that the browser's date picker would be a better choice.
  - jstanley 8y ago
    Even in the event that a browser ships a buggy date picker, at least it would be buggy on every website. The user then has a chance of understanding the bug and working around it to input the correct date.
    - hn_throwaway_99 8y ago
      OK, I'll use another tactic. Show me a single high-traffic travel website that uses the browser's default date picker. Travel websites are usually optimized out the wazoo because small increases in conversion rates make all the difference in this competitive business. Are you saying all those sites (the ones without bugs) are wrong?
  - YawningAngel 8y ago
    The user is responsible for their browser. If they choose to use something that doesn't implement the spec and your site breaks, they sabotaged their own experience. That's very different to you sabotaging their experience.

hn_throwaway_99 8y ago

If it's a "best-practice", I honestly don't know any large, consumer-facing websites that just use input type=date, mainly because that UI sucks in most cases. Even in this case putting the dollar amounts in the dates, which is a very useful piece of information, would need a custom date control.

Splines 8y ago

Is that even a web browser? If you look at the full screenshot, (I'm not 100% familiar with iOS) it looks like an app launched from the app store?

saagarjha 8y ago
That’s almost certainly an app; a web app would require quite a bit of configuration to look like that. It might be running a web view internally, though.

deleted 8y ago

[deleted]