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

Thanks for bringing this up; it's quite a worthwhile discussion.

I think this is a tradeoff. By changing the behavior to make whether a picker was shown or not detectable, we introduce compat issues that constrain browsers from changing their UI in the future. I.e., adding or removing pickers from controls could now become a breaking change for websites. This is an area browsers have been hesitant to be constrained on, in the past.

It also introduces potential interop issues. Right now, if you call showPicker(), it will never throw. But with that proposal, it might work fine in some browsers, and throw in others. This could lead to scenarios where, in the browsers you test with, there's no need for a `catch` block, and so the developer doesn't add one. But then other browsers can't access your site. The same is true for other APIs that expose support, e.g. a boolean return value or a separate canShowPicker() function.

So adding any sort of feature-detection which exposes whether a browser supports a given picker, or not, creates new interop and compat risks that the current proposal doesn't have. But, it makes the proposal more useful for the specific case where a developer definitely wants to show a picker, even if a browser doesn't support it, and thus plans to perform good feature testing and add good fallbacks for such non-supporting browsers.

My instinct is to wait to gather more data on in-the-wild usage to see whether the majority of use cases are:

- It'd be nice to show a picker here, if the browser supports it; otherwise the user can just type; vs.
- I definitely need to show a picker here, and need to know if that won't work, so that I can display my own fallback.

The current API is designed more for the former. If we find out that in the wild people are actually more interested in the latter, then we can consider adding feature detection abilities to serve that use case, and having a cross-browser discussion about whether that's worth the compat and interop risks.

-- 
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-993788883