81–90 of 146 posts
The worst thing that can happen to a website is to use a custom scrolling logic/scrollbar. It never behaves correctly.
Next step would be discovering that we have been doing this since Windows 3.11, and we lost this ability because of web programmers.
As a Dane, pikaday reads a little funny, because "pik" is a vulgar slang term for penis, equivalent to English words like dick or cock.
Earlier quoted context omitted.
That doesn't always work well in practice. I'm bilingual, and my preference is to use the locale closest to the language of the web site I'm visiting because it feels the most culturally coherent and the least surprising. I just can't reset my regional settings whenever I switch tabs.
I also find this annoying, but this is due to websites ignoring the browser preferences. The browser supports specifying multiple languages and the website could select the one that the content is native in.
Earlier quoted context omitted.
This should be called bad advice about dates every developer should avoid. ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking. ISO 8601 only works for dates and times that have already happened. I have 20 years, have worked with apps that relied on future and past dates, have used date pickers since 2005 and would still hesitate to give advice about what is an incredibly…
> ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking. Why is this the case? Is it some time zone shenanigans?
Also you need to take into account where the user is going to be. With future dates, time is relative. So at the very least you often need the time + the timezone of the location.
Book me a table at 8, means book me a table in Berlin time at 8, not in San Francisco time at 8.
Same with displaying future dates, you need the context of where.
Earlier quoted context omitted.
Why were you using a calendar picker for a date of birth?
Could you explain what you mean? We're talking about the OS-native datepicker, which pops up when a user clicks on an HTML .
Earlier quoted context omitted.
Date picker widgets do not solve any validation problem, because validation happens on the server side and client input is not to be trusted.
Obviously, but additionally, providing validation on the frontend can help UX a lot. Doing that can provide much quicker feedback compared to an error thrown at the user only after submitting a form, which can get especially annoying if the latter loses (some of) its values due to submission. And one solution for that problem can be using a native picker.
For dates people know (say date of birth) just use text inputs https://design-system.service.gov.uk/components/date-input/
It's not quite fully supported in browsers but it's a nice enhancement to those where it works.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...