4 ms·

A native date input might be inconsistent between different browsers, or different OSs, but it will be consistent with the native date input on every single oth

A native date input might be inconsistent between different browsers, or different OSs, but it will be consistent with the native date input on every single other website the user goes to. If they're lucky, it will be consistent with the date input field on every other application on their OS. The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date picker on their browser, they know how to use the date picker on your website. If you make them learn how to use a new date picker for your website, it's very unlikely they'll thank you for being able to transfer this unique knowledge to that one website of yours on the very unlikely chance they choose to switch browsers. I mean, who does that regularly? And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. (Or a different OS!) That has the advantage of fixing the native date picker on every single website they go to. Except for the annoying websites which implement their own, where if the custom date picker doesn't work for them, they're fucked. If someone's using a browser with an date picker you happen to dislike, that's their choice. Let them have it.

dmitriid 5y ago
> And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes. Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.
- Karellen 5y ago
  Someone with particular accessibility needs might not be using a popular desktop browser - they'll already be using a user-agent which is adapted to their own needs. If you use native input elements, then whatever accessibility needs a user might have can be accommodated by a user-agent which caters to those needs. And you get that to take advantage of that for free. If you roll your own, you can't cater to people with disabilities that you haven't considered.
  - dmitriid 5y ago
    > Someone with particular accessibility needs Accessibility is not black and white. I have good vision, and native date pickers as implemented in all desktop browsers, are so tiny, I have to zoom the page every time I encounetr them. > If you roll your own, you can't cater to people with disabilities that you haven't considered. True, but you out of hand dismissed huge swaths of people who are not using "adapted user-aganets" but still suffer because browsers have a shitty native implementation.
9dev 5y ago
This is a strange take: Native date pickers are broken in every mainstream browser, which is what the majority of our users use. People don't consciously "choose" browsers. They use whatever was preinstalled or someone recommended them ten years ago. Our customers don't care about other browsers, Open Source software, or the nuance of native input fields. "Look, on AirBnb I can enter dates in a humane way, why is it so hard on your website?" - I just don't get away with recommending them to switch browsers. Having accepted that premise, we can talk about the custom implementations: I would never recommend rolling your own, either. There are several widely used library for date pickers that users are accustomed to, are accessible, and miles ahead of the native controls. There is absolutely nothing wrong with sticking to those libraries until the vendors finally fix their mess.
kmeisthax 5y ago
The funny thing is that, at least on Windows[0], there actually isn't a standard color picker. Or, well, there is, but it's one of those common-controls dialogs that hasn't gotten a UI refresh since Windows 3. People writing native apps that need to pick colors wind up writing their own color pickers[1]. Even Microsoft does this: Paint gives you the same obsolete system color picker I mentioned before, but Paint 3D ships with it's own[2]. If you ask a browser on Windows for a color picker, you get the old-and-busted one. Given the odd bifurcation in Windows UI since 8, I suspect date pickers are the same way, and the one the browser gives you won't actually match what other native apps are doing. So what happens if you decide to do the "right thing", is that you get a demonstrably worse user experience for your forms for the vast majority of people who do not know how to retheme native UI and have zero familiarity with the old Windows controls that browsers continue to throw at people. [0] macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS. [1] Adobe isn't even consistent among their own suite. The Photoshop color picker is entirely different from the Premiere or Animate ones, for example. [2] I suspect the Paint 3D color picker may be a XAML default, but up until very recently the prospects of actually using XAML in most apps was very dim. More specifically, XAML used to be either exclusive to .NET/C#, or exclusive to Microsoft Store apps, neither of which were conducive to native software that need to live outside of an app container sandbox and be distributed through Steam.
- paledot 5y ago
  > macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS. I recall the colour picker being one of the first features that blew my mind upon getting my first Mac running 10.3. I could save swatches OS-wide, I could switch between different selection modes (and install custom modes of my own), and I could even use an eyedropper-like tool to sample any pixel on the screen. There's probably some LinkedIn allegory about attention to detail in there.

dmitriid 5y ago

> And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes. Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.

Karellen 5y ago
Someone with particular accessibility needs might not be using a popular desktop browser - they'll already be using a user-agent which is adapted to their own needs. If you use native input elements, then whatever accessibility needs a user might have can be accommodated by a user-agent which caters to those needs. And you get that to take advantage of that for free. If you roll your own, you can't cater to people with disabilities that you haven't considered.
- dmitriid 5y ago
  > Someone with particular accessibility needs Accessibility is not black and white. I have good vision, and native date pickers as implemented in all desktop browsers, are so tiny, I have to zoom the page every time I encounetr them. > If you roll your own, you can't cater to people with disabilities that you haven't considered. True, but you out of hand dismissed huge swaths of people who are not using "adapted user-aganets" but still suffer because browsers have a shitty native implementation.

9dev 5y ago

This is a strange take: Native date pickers are broken in every mainstream browser, which is what the majority of our users use. People don't consciously "choose" browsers. They use whatever was preinstalled or someone recommended them ten years ago. Our customers don't care about other browsers, Open Source software, or the nuance of native input fields. "Look, on AirBnb I can enter dates in a humane way, why is it so hard on your website?" - I just don't get away with recommending them to switch browsers. Having accepted that premise, we can talk about the custom implementations: I would never recommend rolling your own, either. There are several widely used library for date pickers that users are accustomed to, are accessible, and miles ahead of the native controls. There is absolutely nothing wrong with sticking to those libraries until the vendors finally fix their mess.

kmeisthax 5y ago

The funny thing is that, at least on Windows[0], there actually isn't a standard color picker. Or, well, there is, but it's one of those common-controls dialogs that hasn't gotten a UI refresh since Windows 3. People writing native apps that need to pick colors wind up writing their own color pickers[1]. Even Microsoft does this: Paint gives you the same obsolete system color picker I mentioned before, but Paint 3D ships with it's own[2]. If you ask a browser on Windows for a color picker, you get the old-and-busted one. Given the odd bifurcation in Windows UI since 8, I suspect date pickers are the same way, and the one the browser gives you won't actually match what other native apps are doing. So what happens if you decide to do the "right thing", is that you get a demonstrably worse user experience for your forms for the vast majority of people who do not know how to retheme native UI and have zero familiarity with the old Windows controls that browsers continue to throw at people. [0] macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS. [1] Adobe isn't even consistent among their own suite. The Photoshop color picker is entirely different from the Premiere or Animate ones, for example. [2] I suspect the Paint 3D color picker may be a XAML default, but up until very recently the prospects of actually using XAML in most apps was very dim. More specifically, XAML used to be either exclusive to .NET/C#, or exclusive to Microsoft Store apps, neither of which were conducive to native software that need to live outside of an app container sandbox and be distributed through Steam.

paledot 5y ago
> macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS. I recall the colour picker being one of the first features that blew my mind upon getting my first Mac running 10.3. I could save swatches OS-wide, I could switch between different selection modes (and install custom modes of my own), and I could even use an eyedropper-like tool to sample any pixel on the screen. There's probably some LinkedIn allegory about attention to detail in there.