Re: [w3ctag/design-reviews] HTMLInputElement showPicker() (Issue #688)

It's anecdata (and real-world data wins ofc), but I can assure you that the 'I really want a picker here (because users typing dates is extremely error-prone), and would prefer the native one, but will roll my own if I have to' situation has happened to me. There are also a *lot* of UI widgets out there implementing date pickers, and I expect most of them fail somewhere on a11y, i18n, and l10n, so user experience would be well served if they can use a native picker that gets it right when available. 

Provided that `showPicker()` fails predictably when a given picker isn't available from day one I think the potential risk of interop problems is fairly low. Especially as not all UAs are likely to implement all the possible pickers at the same time, authors will have plenty of incentive to detect failure. Historically some UAs didn't even support date pickers on all platforms (not sure about current reality there).

If `showPicker()` sometimes throwing exception is problematic, there are other approaches like simply returning null that would be less disruptive. Note also it's important to be able to tell the difference between a UA failing to display a picker vs the user dismissing the picker with no selection. (Maybe if a user dismiss also throws an exception then everyone has to deal with exceptions...)

Which brings up another thought, what about accepting an AbortSignal in showPicker()?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/688#issuecomment-993861485