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

> > Since programmatic clicks already trigger the picker on color and file inputs, why not just specify that programmatic clicks trigger the picker on all inputs and avoid the additional API surface?
> 
> That's one direction we could go in, but I worry that it's a bit unexpected. click() rarely has these sorts of side effects, and the fact that it does so on file and color feels like a legacy quirk instead of something we want to extend. 

`.click()` has major side effects already, e.g. calling it on an `<a>` element can navigate to another page! Doesn't get any more side effect-y than that! 😁 

> There's also a minor compat risk that people are calling click() and expecting no-op behavior today... although I doubt it'd be that risky.

Yeah, I agree I wouldn't expect that to be common.

The way I see it, the advantages of `.click()` triggering the picker instead of a separate method are:

- It's usually the first thing authors try, even before they research the API surface, so it's good for discoverability
- If there are any event listeners attached to clicks with the assumption that they will be triggered every time the picker is opened, this will trigger them too

One downside is that it couples synthetic clicks with opening the picker: is there any case where authors may want to do one without the other?

> I think the main argument is one I allude to in [whatwg/html#3232](https://github.com/whatwg/html/issues/3232), which is that by not tying pickers to clicks, we allow a broader possible range of browser UIs for form controls, both now and in the future. Which has always felt important to me, given how we've seen things evolve with smartphones and watches and so on.

If I understand your point correctly (?), you are saying that browsers in the future may want to provide more granular UIs which display different pickers depending on the location of the click, and thus a general `.click()` cannot really describe these kinds of interactions, whereas `.showPicker()` can be extended to support granularity via arguments.

I see that in theory, though why not add a separate API call then, *if* that happens? They're not mutually exclusive. Then `.click()` can do the same thing as `.showPicker()` if called with no arguments.

I could be wrong, but it seems inconsistent to me to have `.click()` trigger only *some* pickers, and add a separate method to trigger the rest. 🤷🏽‍♀️ It also seems to diverge a bit from the past direction of "the HTML spec leaves UI up to implementations", whereas at least `.click()` is more .




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