61 ms·

> I didn't write a date picker. Again, HTML5. Is this really possible? I remember that the html5 datepicker isn't working at all on some browsers (or on mobile

> I didn't write a date picker. Again, HTML5. Is this really possible? I remember that the html5 datepicker isn't working at all on some browsers (or on mobile). Are there any data on the percentage of users that won't see a datepicker at all if they go the html5 route?

diocles 3y ago
Support looks pretty reasonable (works for 95% of global users) with some caveats around Safari: https://caniuse.com/input-datetime https://caniuse.com/input-datetime
Alifatisk 3y ago
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
chrisco255 3y ago
It works...ish. It provides an inconsistent experience across browsers, and if your datepicker needs any other functionality besides picking a single date, such as date ranges, focused dates, rendering two or more months at a time, rendering a weekly view, etc, you're going to have to use JS.
baz00 3y ago
No it's not. It sort of works until you have to deal with thinks like international dates when the thing isn't rendered or breaks (which happens a lot on android from experience). Then some end user inserts an invalid date like 2023-02-31 so you still have to do server-side validation or check it with some client JS anyway. So you might as well just chuck some shitty jQuery control over the top of it. Basically as always with HTML it's half baked and half supported.
- deleted 3y ago
  [deleted]
- maccard 3y ago
  > Basically as always with HTML it's half baked and half supported. As opposed to home rolled js replacements for browser features?
  - baz00 3y ago
    Both are terrible. The whole web is terrible. I wish for Gopher, nicely presented PDFs, thick apps and APIs and for the whole hypertext steaming pile of mess to crawl back to where it came from.
    - maccard 3y ago
      Good, performant, well designed apps and systems still exist. Absolute steaming piles of crap that didn't interoeprate existed "before the web" too. > I wish for Gopher, nicely presented PDFs, thick apps and APIs You're free to browse Gopher sites, only read latex documents, and stick to Desktop apps. PDF's are a great example of an absolute steaming pile of nonsense though. They're page layouts (that don't map to my 16:9 widescreen monitor, or to my 20:9 phone), have poor standards for layout and linking, and behind the scenes are just a mess of rules that are practically impossible to interpret, even on PDF's that aren't obfuscated. PDF's are a disaster, and I'd pick a css/js/html document over a PDF any day.
      - baz00 3y ago
        I couldn’t disagree more. It’s nice reading them on my iPad especially properly typeset ones.
  - nsonha 3y ago
    Who said home rolled?
- wild_egg 3y ago
  > you still have to do server-side validation Yes you do, regardless of how fancy your JS widgets are. Always do server-side validation. Always

diocles 3y ago

Support looks pretty reasonable (works for 95% of global users) with some caveats around Safari: https://caniuse.com/input-datetime https://caniuse.com/input-datetime

Alifatisk 3y ago

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

chrisco255 3y ago

It works...ish. It provides an inconsistent experience across browsers, and if your datepicker needs any other functionality besides picking a single date, such as date ranges, focused dates, rendering two or more months at a time, rendering a weekly view, etc, you're going to have to use JS.

baz00 3y ago

No it's not. It sort of works until you have to deal with thinks like international dates when the thing isn't rendered or breaks (which happens a lot on android from experience). Then some end user inserts an invalid date like 2023-02-31 so you still have to do server-side validation or check it with some client JS anyway. So you might as well just chuck some shitty jQuery control over the top of it. Basically as always with HTML it's half baked and half supported.

deleted 3y ago
[deleted]
maccard 3y ago
> Basically as always with HTML it's half baked and half supported. As opposed to home rolled js replacements for browser features?
- baz00 3y ago
  Both are terrible. The whole web is terrible. I wish for Gopher, nicely presented PDFs, thick apps and APIs and for the whole hypertext steaming pile of mess to crawl back to where it came from.
  - maccard 3y ago
    Good, performant, well designed apps and systems still exist. Absolute steaming piles of crap that didn't interoeprate existed "before the web" too. > I wish for Gopher, nicely presented PDFs, thick apps and APIs You're free to browse Gopher sites, only read latex documents, and stick to Desktop apps. PDF's are a great example of an absolute steaming pile of nonsense though. They're page layouts (that don't map to my 16:9 widescreen monitor, or to my 20:9 phone), have poor standards for layout and linking, and behind the scenes are just a mess of rules that are practically impossible to interpret, even on PDF's that aren't obfuscated. PDF's are a disaster, and I'd pick a css/js/html document over a PDF any day.
    - baz00 3y ago
      I couldn’t disagree more. It’s nice reading them on my iPad especially properly typeset ones.
- nsonha 3y ago
  Who said home rolled?
wild_egg 3y ago
> you still have to do server-side validation Yes you do, regardless of how fancy your JS widgets are. Always do server-side validation. Always