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

> > @drwez 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?
> 
> Currently the spec doesn't define the behavior of `charCode` at all

Are you sure you're looking at the latest draft? https://www.w3.org/TR/uievents/#dom-keyboardevent-charcode has a(n admittedly self-contradictory[1]) description of the common behaviour.

Specifically note the expectation that a `charCode` is a `charCode` in the `DOMString` sense of the term, such that it can be passed to `String.fromCharCode()` for example.

[1] Which is in part what lead to this spec bug :)

> Although it's a legacy API, it's still commonly used, so it's still important for its behavior to be consistent among browsers.

While that would be ideal, what's most important is that its behaviour is consistent with what content has previously been lead/forced to accommodate.  Historically the `keypress` event, and the content of `charCode` has _not_ been consistent across _platforms_, even for the same cross-platform browser. It has been common practice for content to accommodate the various different behaviours by checking the browser, platform and/or versions in the User-Agent string.

There has been a push to use e.g. the presence or absence of fields to detect what's needed (e.g. this was the case historically with `which` vs `keyCode` etc) but there have also been behaviours that are harder to accommodate that way (e.g. `keyCode` used Windows-style VKEYs under IE, and WebKit-based browsers on all platforms, but a different system under Firefox on Linux, IIRC).

> Ideally the spec should be changed so that `charCode` is more tightly specified (perhaps aligning with Safari), and that `charCode` should never contain surrogate pairs.
>
> If those spec changes cannot be made (for compat reasons), then we just have to accept that.

Right; the spec cannot _mandate_ any particular behaviour, in general, since this is a legacy compatibility event.

The spec could _recommend_ a behaviour, if an implementation is free of compatibility concerns.

> So the big question is: how likely are there to be compat issues if Chrome / Firefox align to Safari's behavior? That will decide what sort of spec changes (if any) need to be made.

Right; enumerating the four main implementations we have:

1. Don't emit `keypress` at all for non-BMP characters, only `input`.
    * Reasonable given that legacy content typically pre-dates non-BMP being relevant, and new content should be migrating to `input` anyway.
    * Would break content relying on two-`keypress` w/ `charCode` holding the code-units, as under Chrome on Windows, and Firefox across all(?) platforms.
    * Would break content expecting `keypress` with `charCode` containing a character code-point, as is possible with Safari, IIRC.

2. Emit two `keypress` events, with `charCode` set to each of the surrogates.
    * Awkward to implement for non-Windows platforms.
    * Breaks compatibility for "whole character" `charCode` browsers, like Safari.
    * Does not line-up well with `input` (e.g. what happens if one or other `keypress` is cancelled?).

3. Emit a single `keypress` with `charCode` set to a whole character.
    * Breaks content that assumes that `charCode` can be e.g. passed to `String.fromCharCode()`.
    * Only content designed for Safari would presumably already have arranged to be compatible?

4. Emit a single `keypress` with `charCode` set to one of the surrogates.
    * `charCode` is not useful, and content that uses it will not work correctly, including stuff that previously would have worked under Chrome/Windows.
    * Implies that content should use the `key` field to get the actual character data, which would be strange, since if content is going to be updated, it should be updated to use `input`.

To make another specific proposal, I'd suggest the spec:
[0. Continue to try to get `input` fixed in the implementations!]
1. Acknowledge options 1, 2 and 3 as known implementations, preferably with some context to help folks understand how common to expect them to be.
2. Recommend one of the options as preferred for implementations with no unique compat considerations of their own. Maybe also discourage option 4.
3. Provide a code-snippet to show how to patch-up existing `fromCharCode()` using content to work with both options 2 and 3.

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

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