Re: [w3c/uievents] Clarify `keypress` event handling for keys that map to non-BMP Unicode symbols (Issue #346)

> Again, this bug is specifically about the legacy keypress event, and the charCode field, for which the web platform spec is non-normative. Historically two keypress events have, in the past, in various implementations, been emitted for non-BMP characters - so it can't be said that emitting only one is more (or less) correct. :)

Historically it hasn't always been two keypress. It depends on the browser.

The `input` and `keypress` bugs are connected, they're not isolated.

`charCode` does complicate things a bit, but since Safari has always produced 1 event, and IE / EdgeHTML also produce 1 event,  that makes things *easier*.

When browsers disagree, that makes it *easier* for the browsers to choose the correct behavior, because there is less concern about compat issues.

That has happened many times in the past, where browsers disagreed on the behavior, and so it was easy to align all of the browsers to the correct behavior.

> so it can't be said that emitting only one is more (or less) correct. :)

No, the correct behavior is obviously to have 1 event. The only reason for having 2 events is for historical compat reasons.

That's why we're discussing the probability of compat issues. If the probability is low, then perhaps the browsers can just fix the bug.

You claim the probability of compat issues is high, because non-BMP characters are rarely used. But as I said in my earlier post, that's not true, because emojis are non-BMP and they're commonly used.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/346#issuecomment-1631115554
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents/issues/346/1631115554@github.com>