search

w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
147 stars 51 forks source link

Dead keys and unsupported base characters #120

Open r12a opened 7 years ago

r12a commented 7 years ago

5.3.3. Dead keys https://w3c.github.io/uievents/#keys-dead

This process might be aborted when a user types an unsupported base character (that is, a base character for which the which the active diacritical mark is not available) after pressing a dead key:

Are we saying here that the spec recommends this behaviour, or just describing what sometimes happens?

The description in the spec may just be following current practice, but i wonder why the sequence ¨+q shouldn't just produce q̈ if there's no single character to map it to.

asmusf commented 7 years ago

If sequences cannot be returned, that should be spelled out. In that case, "not available" should be defined as "is not a single code point in NFC"

r12a commented 4 years ago

Any resolution for this?

asmusf commented 4 years ago

I'm not sure I follow the example 27. It looks as if in the end, nothing is returned.

On Windows (for example with the standard German keyboard), when I type a dead key for the acute accent followed by a character not supported (q), I get a spacing accent followed by the letter ( ´q ) as an indication that something didn't go as planned. (That two character sequence is echoed on keyup for q).

It would be strange if it worked one way in some applications and not others.

I'm not sure what other keyboard layouts do (e.g. those supporting diacritics for which there isn't a spacing clone). The upshot is that it looks like it's not a universal behavior and in cases where users have installed a particular keyboard, the expectation would seem that that selection drives the policy.