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

The `input` and `keypress` issues are related, but different:

`input` is defined by this spec, and its specified behaviour already matches the one-event model that will address the bug you linked - so no spec changes are required, only fixes by the browser vendors.

`keypress` has a non-normative description in the spec, and is explicitly provided for "historical compat"ibility, with content that pre-dates the `input` specification.

Again, the fact that emoji are commonly-used doesn't necessarily mean that they are commonly-used in conjunction with web content that happens to also use the `charCode` field of `keypress` events to receive them (instead of `input`/`data`) - and even in the implementations with broken `keypress.charCode` or `input.data` the implementations do end up with non-BMP characters correctly appearing in standard text fields.

Given that the `input` spec already does what you describe, and that it falls on vendors to apply fixes for that, do you object to having the existing `keypress` behaviours better-described by the non-normative portion of the spec?  If so then could you provide a specific alternative proposal?

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

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