Keystrokes on <datalist> should not fire events on <input>

[LeaVerou]

The behavior seems to currently be undefined in the spec, and non-interoperable in UAs: Chrome does not fire such events, Firefox and Edge do.

The reasonable way to go is to NOT fire such events or, even better, to fire them on the <datalist> element.

Firing those events on the input makes it impossible to distinguish them from "real" keystrokes. For example, you may want Enter on the input of a to-do list to insert an item, but that shouldn't happen if Enter is pressed to select a datalist option. There is currently no way to distinguish the former from the latter in Firefox and Edge.

Related Bugzilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1360755

[domenic]

For example, you may want Enter on the input of a to-do list to insert an item, but that shouldn't happen if Enter is pressed to select a datalist option.

This is pretty compelling.

To be clear, you're talking about things like using the up/down arrows, pressing enter or tab, etc., should not fire key events, right? But actually selecting something should still fire input/change.

Some might argue this is in the realm of UI and thus outside the spec (e.g., it's up to the browser if it wants to attach special meaning to certain key events, like treating Enter as a "select an item" behavior instead of its usual do-nothing). But I think we can clamp things down a bit.

[LeaVerou]

To be clear, you're talking about things like using the up/down arrows, pressing enter or tab, etc., should not fire key events, right? But actually selecting something should still fire input/change.

Yes, of course.

Some might argue this is in the realm of UI and thus outside the spec (e.g., it's up to the browser if it wants to attach special meaning to certain key events, like treating Enter as a "select an item" behavior instead of its usual do-nothing). But I think we can clamp things down a bit.

It doesn't have to specify anything about specific keys, just that keyboard events on the list (and that should apply to any autocomplete list, both the one datalist produces and other types of autocomplete) should not be fired on the <input>. It could even clarify that input/change should still be fired if a choice is made (if that's deemed non-obvious).

[domenic]

Looking at this a bit more I'm not sure there's a good place in the HTML spec to slot this. We don't currently say very much about keyboard events in the HTML spec. I think UI events might be the spec that's supposed to handle that? See e.g. https://w3c.github.io/uievents/#events-keyboard-types. I guess that currently says

If the key is the Enter or key and the current focus is on a state-changing element, the default action MUST be to dispatch a click event, and a DOMActivate event if that event type is supported by the user agent (refer to §3.5 Activation triggers and behavior for more details)

which doesn't seem quite right in this case.

@garykac, any ideas here on the UI events side? Maybe we need a clause about how keystrokes used to manipulate UI widgets might not generate key events at all?

@foolip, any ideas here on how we can nail this interop issue, despite the specs not having great coverage of this area?

[foolip]

Firing those events on the input makes it impossible to distinguish them from "real" keystrokes. For example, you may want Enter on the input of a to-do list to insert an item, but that shouldn't happen if Enter is pressed to select a datalist option. There is currently no way to distinguish the former from the latter in Firefox and Edge.

Maybe relatedTarget could come to the rescue here?

Handwavy language about input events in HTML isn't entirely without precedence:
https://html.spec.whatwg.org/multipage/embedded-content.html#user-interface

("then the user agent should suppress any user interaction events while the user agent is interacting with this interface")

What is the behavior we should try to converge on, though?

[domenic]

I guess this might be more widespread than we realized, considering other inputs like color, date/datetime-local, and even number. Do clicking on or using keyboard shortcuts to interface with those widgets trigger events? Probably we should use the same answer for those as for inputs with a datalist.

It makes sense to me to converge on the Chrome behavior, of suppressing such events while interacting with that user interface (and thanks for finding a spec precedent for that!).

[LeaVerou]

Do clicking on or using keyboard shortcuts to interface with those widgets trigger events?

Not sure what you mean, but yeah, using keyboard shortcuts in a date input's widget shouldn't fire keyup events. Pressing arrow keys to increment a number input should though, since these are used directly on the input.

[garykac]

UIEvents doesn't currently describe these events algorithmically, but when it does that algorithm would be a good place for this info.

For now, the info could just be placed in a Note by the event description. Long/medium-term, we want to update UIEvents with proper algorithms.

In the meantime, I have a bug in UIEvents to track specifying the algorithm for key events: w3c/uievents#142