- From: Henri Sivonen <notifications@github.com>
- Date: Thu, 29 Jun 2023 11:39:41 -0700
- To: w3c/uievents <uievents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/uievents/issues/346/1613620837@github.com>
> My description was in relation to the events received from the platform, not the way that those events are interpreted by the user agent Is it known that IE and EdgeHTML use the same system API surface as Gecko and Blink? Notably, https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-unichar seems to exist. > The `keypress` behaviour shown for IE and EdgeHTML don't really make sense, since the `charCode` field has a bogus value Indeed the `charCode` part doesn't make sense. However, the `key` field is consistent with Safari: https://hsivonen.fi/screen/safari-adlam.png . This is a pretty strong indication that it's Web-compatible to emit one sequence of keyboard events per Unicode Scalar Value and to represent the Unicode Scalar Value as two UTF-16 code units in the `key` field. > That the two implementations differ in their choice of `charCode` value suggests that the behaviours were artefacts of an implementation choice, rather than a conscious decision. Yes, but the bogus values suggest that it's not that likely for the Web to be relying on `charCode`, which means it's quite possible that it would be feasible for other engines to align to Safari's behavior, which (absent Web compat constraints to the contrary) is clearly the best behavior (no unpaired surrogates, `charCode` integer shows the same scalar value as the `key` string). The Chrome Mac behavior (https://hsivonen.fi/screen/chrome-mac-adlam.png) also suggests that it should be Web-compatible to align to the Safari behavior. > From my perspective, the primary problem here is when 2 separate event sequences are sent when the user enters a single character. I think the primary problem with splitting non-BMP characters across events is that (as far as I know) this is the only case where the environment that JS/Wasm runs in introduces unpaired surrogates. In every other case, environment-supplied DOMStrings are actually well-formed UTF-16 and the only way for a site-supplied program to get an unpaired surrogate in a string returned by a browser API is to first offer an unpaired surrogate as input to a browser API. Therefore, these events are the only place in the platform that breaks the mappability of DOMString to the native string type of compiled-to-Wasm languages whose native string type's value space is a sequence of Unicode Scalar Values. For practical purposes today, this means Rust, but in principle it also means Swift (which, as I understand it, isn't a common compile-to-Wasm language _today_). That multi-scalar-value emoji that is a single user-perceived character and a single press of a Windows 10 touch keyboard "key" gets spread across multiple events is not a problem for the perspective of mappability to Rust (or Swift) strings, since the `key` field of each event is well-formed UTF-16. Mac: https://hsivonen.fi/screen/safari-adlam.png https://hsivonen.fi/screen/firefox-mac-adlam.png https://hsivonen.fi/screen/chrome-mac-adlam.png Firefox on Windows: https://hsivonen.fi/screen/firefox-windows-greek.png https://hsivonen.fi/screen/firefox-windows-adlam.png https://hsivonen.fi/screen/firefox-windows-emoji.png https://hsivonen.fi/screen/firefox-windows-facepalm.png Chrome on Windows: https://hsivonen.fi/screen/chrome-windows-ascii.png https://hsivonen.fi/screen/chrome-windows-greek.png https://hsivonen.fi/screen/chrome-windows-adlam.png https://hsivonen.fi/screen/chrome-windows-emoji.png https://hsivonen.fi/screen/chrome-windows-facepalm.png Notably, Chrome on Windows treats Adlam, which is an actual keyboard layout, as an IME even though it treats the emoji touch keyboard as a keyboard! Considering that Chrome on Windows doesn't even appear to treat non-BMP keyboard layouts as keyboard layouts (even though IE, EdgeHTML, and Firefox treat them as keyboard layouts), I have a really hard time believing that the Web Platform couldn't converge on the combination of Safari and Windows 10 touch keyboard behaviors: 1. Emit each Unicode Scalar Value as one event sequence like in EdgeHTML with the Windows 10 touch keyboard. 2. Make the `key`/`data` and `charCode` fields of the events in each such sequence look like they do in Safari on Mac. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/uievents/issues/346#issuecomment-1613620837 You are receiving this because you are subscribed to this thread. Message ID: <w3c/uievents/issues/346/1613620837@github.com>
Received on Thursday, 29 June 2023 18:39:47 UTC