I'm working on keyboard shortcuts for a web application and need to check if a keypress should trigger the shortcut or if it is just the user typing and should therefore not trigger the shortcut.
For example, a common pattern is to use the / or s keys to open the global search bar. Obviously this should not open the search bar if the user is typing into another input.
The ideal logic would go something like this: On keypress, check the currently focused element. If the element accepts keyboard input (can be typed into), then do nothing. If the element does not accept keyboard input, run the shortcut.
Note that checking for focusability is not enough because links and buttons are focusable, but do not accept keyboard input (in the way I mean here).
Here's what I have so far:
function acceptsKeyboardInput(element) {
return (
element.tagName === "INPUT" ||
element.tagName === "TEXTAREA" ||
element.isContentEditable
);
}
Does this approach catch every case or is there a better way to tell if an HTML element accepts keyboard input?
Will all shortcuts be more than one key? If so you can listen for input and prevent a shortcut from running with a boolean value.
var is_input = false
window.addEventListener('keydown', function (e) {
console.log(is_input)
is_input = false
})
window.addEventListener('input', function (e) {
is_input = e.constructor.name == 'InputEvent'
})
Expected output for /s while able to type would be true or false (depending on the previous is_input value) at / keypress then true at s keypress and all keys following.
Expected output for /s while not able to type would be true or false (depending on the previous is_input value) at / keypress then false at s keypress and all keys following
From what I've seen, the suggestion given in the question seems to be the best approach—with some adjustments.
The first improvement is to blacklist a set of input types that don't accept keyboard input (e.g. checkbox or radio). I find it easier and better to use a blacklist rather than a whitelist for two reasons. The first is future-proofing against newly supported input types and in case you miss one. Second and more importantly, an invalid input type defaults back to type text, which means there are an infinite number of input types that accept keyboard input.
The second change is to also include <select> elements since they can be typed into as a sort of search/quick-select functionality.
Here's the full function:
const nonTypingInputTypes = new Set([
"checkbox",
"radio",
"button",
"reset",
"submit",
"file",
]);
export function acceptsKeyboardInput(element) {
return (
(element.tagName === "INPUT" && !nonTypingInputTypes.has(element.type)) ||
element.tagName === "TEXTAREA" ||
element.tagName === "SELECT" ||
element.isContentEditable
);
}
There are a few other inputs that don't accept keyboard input but that are less widely supported by browsers (e.g. color), so I've tried to keep it to the more commonly used and widely implemented input types.