Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released.
Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
What autocompletes are you testing? I set my repeat delay to be very long so it doesn't interfere with the test, and then went to google and held down some keys for half a second. It types the letter and autocompletes long before I let go.
Every UI I can find types the letter on keydown, and I don't know why you'd want typing and autocomplete to use different timings.
Waiting for release is for mice and touch, not keyboards. And that's only because they have to deal with dragging.
Comments
Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released.
Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
Why would you argue that makes more sense? That is not how any autocomplete works that I know of, it's not like this is a new pattern.
What autocompletes are you testing? I set my repeat delay to be very long so it doesn't interfere with the test, and then went to google and held down some keys for half a second. It types the letter and autocompletes long before I let go.
Every UI I can find types the letter on keydown, and I don't know why you'd want typing and autocomplete to use different timings.
Waiting for release is for mice and touch, not keyboards. And that's only because they have to deal with dragging.
Your test is flawed, it's triggering keyup if it's showing in the input.
I go to the text box in HN and hold down a key.
The letter appears instantly, then after a moment a lot more copies of the same letter start showing up rapid-fire.
What are you calling flawed about my test?
This happens on both Windows 10 and Linux Mint, in Firefox.
Overall the correct event to listen to would be the input even not the keydown event since it handles the edge cases I mentioned earlier
I never meant to infer that the keyup event is specifically what should be listened to