Key Event Codes & JavaScript KeyCode

1. Por qué keyCode quedó como propiedad heredada

La especificación UI Events del W3C conserva KeyboardEvent.keyCode y KeyboardEvent.which solo como propiedades heredadas, documentadas por compatibilidad. El problema es que nunca hubo una tabla común: la tecla ";" emite 186 en Chrome, Edge y Safari, pero 59 en el Firefox histórico, y los navegadores devuelven 0 en muchas teclas dentro del evento keypress, que también quedó obsoleto. Los reemplazos normalizados son key, con el valor efectivo del carácter o el nombre de la acción, y code, con el identificador de la tecla física; ambos tienen listas cerradas de valores en las especificaciones "KeyboardEvent key Values" y "KeyboardEvent code Values". Para texto que se está insertando, lo correcto es escuchar beforeinput o input en lugar de deducir caracteres desde keydown.

2. event.key frente a event.code: significado o posición

code identifica la posición física tomando como referencia el teclado US QWERTY: la tecla de la esquina izquierda de la fila central siempre reporta KeyA, aunque en un AZERTY francés esté impresa como Q y en un QWERTZ alemán la Y y la Z aparezcan intercambiadas. key, en cambio, devuelve lo que la distribución produce en ese momento: "a" sin Shift, "A" con Shift y "q" en AZERTY. Por eso los controles WASD de un juego se leen con code (KeyW, KeyA, KeyS, KeyD) y los atajos semánticos con key (Enter, Escape, ArrowUp). El teclado numérico deja la diferencia a la vista: el 1 del numpad tiene code Numpad1 y el de la fila superior Digit1, pero los dos tienen key igual a "1".

3. Modificadores, repetición, location e isComposing

KeyboardEvent expone banderas booleanas para ctrlKey, shiftKey, altKey y metaKey (Cmd en macOS, tecla Windows en PC), y getModifierState() permite consultar estados que no tienen bandera propia, como CapsLock, NumLock o AltGraph. La propiedad repeat vale true en los keydown que el sistema genera al mantener una tecla apretada, útil para no disparar una acción cientos de veces. location distingue duplicados (0 estándar, 1 izquierda, 2 derecha, 3 numpad), igual que ShiftLeft y ShiftRight en code. Y isComposing indica que hay una composición en curso con un IME de japonés, chino o coreano: mientras sea true conviene no interceptar teclas, porque Enter confirma candidatos en vez de enviar el formulario.

¿Por qué event.keyCode devuelve 229 en Android o con un IME activo?

229 es el valor "processed" que envían los navegadores cuando la tecla la consume el editor de método de entrada o el teclado predictivo del móvil; en esos casos key llega como Unidentified. No hay forma de recuperar el carácter desde keydown: hay que leerlo de los eventos beforeinput e input o del value del campo, y esperar a que isComposing vuelva a false o a que se dispare compositionend.

¿Por qué mi atajo Ctrl+S deja de funcionar en otra distribución de teclado?

Si lo comparás contra event.key, el valor cambia con la distribución y con los modificadores: con Shift llega "S" y con AltGr puede llegar otro carácter. Para atajos ligados a una posición usá event.code === "KeyS"; si te interesa la letra, normalizá con key.toLowerCase(). Tené en cuenta además que en Windows AltGr se reporta como ctrlKey y altKey a la vez, lo que puede activar por error atajos de Ctrl+Alt.

¿Por qué no recibo el evento keyup de algunas teclas en macOS?

Mientras se mantiene apretada la tecla Cmd, macOS no entrega el keyup de las demás teclas, así que un registro de teclas presionadas queda desincronizado. También faltan keyup cuando la ventana pierde el foco a mitad de una combinación. Lo habitual es limpiar el conjunto de teclas activas en los eventos blur y visibilitychange en vez de confiar solo en keyup.