Hacker News Reader

Comment by weird-eye-issue | Hacker News Reader

There are a large number of edge cases where rendering it on key down would not be desirable (user types Ctrl+v, how accented characters are enetered, how some Asian languages get handled, backspace/delete, user holds a key down, etc). This is getting into the point of optimization where it simply does not matter and can actually harm things

View on HN

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

Reply on news.ycombinator.com