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

Focusing on the scope of this bug (i.e. just the spec, not the bugs in the various implementations), it sounds like there are one or two AIs:

1. Revise the wording around `keypress`:
    - Describe the two-events-per-non-BMP-character expectation, and correct the wording around the "common" content of `charCode` (that it historically holds a UTF16 code-unit, not a Unicode code-point as is currently claimed).
    - Describe the alternative single-event-with-code-point behaviour, as informational specification. We might also provide a snippet of the rudimentary logic required to cope with both behaviours.

2. Add explicit wording to `input.data`'s specification regarding whether implementations MUST, or SHOULD, or needn't, ensure to deliver non-BMP characters whole, or whether events with `input.data` containing individual surrogates are acceptable.

Depending on the agreement for #2, it looks like Firefox and Chromium would then need their `input` behaviour fixing.

Separately there is the question of whether `keypress` events should have non-trivial values set for the modern fields we specified for use in `keydown` and `keyup` events (notably `key` or `code`), so I've filed https://github.com/w3c/uievents/issues/349 for that to be discussed.

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

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