Dead keys are not intuitive

by Michael S. Kaplan, published on 2004/12/17 02:27 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2004/12/17/323257.aspx

The dead key mechanism in keyboard layouts is rooted in European typewriters. One would type the accent character and the typewriter's head would not advance, then one would type the base character and it would. The term dead key refers to the fact that the position is not advanced after typing the diacritic mark.

So since people are used to this from typewriters, adding a similar mechanism to Windows should be easy, right?

Well, no.

After all, if you are used to Unicode then you know that one first types the base character and then the diacritic. If you are used to typewriters, you expect to see the diacritic. And in both cases you expect that what is finally produced is always made up of the constituent parts that were typed.

In keyboard layouts on Windows, none of these assumptions are true. Nothing is visible after typing the dead key. The layout defines what is to appear when the combination of the dead key and the base character is typed and there is no rule guiding what must appear.

This is a mechanism that is very easy and intuitive if you know about it, otherwise it is as confusing as hell.

Also, you can only have each pairing of keystrokes produce a single UTF-16 code point. I would not have believed it, but this limitation is one of the most common questions I am asked about (not #1 but definitly in the top five -- most often to do with user-created Polytonic Greek keyboards since there is no precomposed form in Unicode). This is not an MSKLC limitation, it is a core limitation in the keyboard layout architecture, as one can find in the kbd.h header file from the Windows DDK (available to all for a mere $199 plus s/h):

/***************************************************************************\
*
* Dead Key (diaresis) tables
*
* LATER #####: supplant by an NLS API that composes Diacritic+Base -> WCHAR
*
\***************************************************************************/
typedef struct {
    DWORD  dwBoth;  // diacritic & char
    WCHAR  wchComposed;
    USHORT uFlags;
} DEADKEY, *KBD_LONG_POINTER PDEADKEY;

There is only room for a single WCHAR for the precomposed character. Sorry! 

There is also a comment above the struct by someone who no longer works on keyboards (their name removed from above for obvious reasons!), and no NLS API was ever added for the sake of keyboards that would combine the two characters to create the dead key. Technically one already exists -- the FoldString API with the MAP_PRECOMPOSED flag. However, such an API could never be used at this point, since there has been many years of potential keyboard layouts shipped that allow one to attach to two unrelated characters a third unrelated character.

(I'll see about talking to someone about removing the comment!)

Now one thing that is possible in the Windows architecture is chaining dead keys together, so that a dead key plus a base character will then wait treat the combination as another dead key waiting for yet a third base character. One could then chain that as well, and so on -- adding more and more keystrokes to produce in the end a single code point. This feature is not currently supported by MSKLC since the demand for combinations of three or more keystrokes always involve multiple characters being produced -- one is simply not enough here for anyone who has ever asked....

On the whole, my earlier words about dead keys sum up the situation best:

This is a mechanism that is very easy and intuitive if you know about it, otherwise it is as confusing as hell.

Luckily there are many ways to produce input with keyboards that is much more intuitive to potential users. Lets leave dead keys for the people who are used to them.

# Anonymous on 17 Dec 2004 6:56 AM:

# Jake on 17 Dec 2004 6:58 AM:

# Michael Kaplan on 17 Dec 2004 8:04 AM:

# Michael Kaplan on 17 Dec 2004 8:05 AM:

# Ben Hutchings on 17 Dec 2004 8:28 AM:

# Michael Kaplan on 17 Dec 2004 8:42 AM:

# Chris Nahr on 18 Dec 2004 1:13 AM:

# Michael Kaplan on 18 Dec 2004 3:52 AM:

# Chris Nahr on 19 Dec 2004 12:58 AM:

Michael Everson on 19 Jun 2009 10:26 AM:

referenced by

go to newer or older post, or back to index or month or day