With many browser and OS combinations, there is no way to trigger this shortcut on a german layout. However, this does not work on Firefox, and neither does it work on Chrome on macOS. Using Chrome on Linux with a german keyboard, my # key will produce the required ke圜ode for triggering / shortcuts. When implementing a shortcut key handler, the keypress event is usually better. As described above, the ke圜ode attribute is not useful for printable characters, especially those input with the Shift or Alt key pressed. Web developers shouldn’t use the ke圜ode attribute for printable characters when handling keydown and keyup events. It is very clearly documented that this should not be done and that it is not compatible across layouts, operating systems, and even browsers. Still a vast majority of web applications use the keydown evente with these properties. These event properties are simply not suited for finding out which character was pressed, at least when used with keydown or keyup. Why is this a problem? For starters, all three properties are deprecated. It uses ke圜ode, which, or charCode to find out which key was pressed. Let key = event.ke圜ode || event.which || event.charCode Most applications use a Javascript library that handles all these things for them, primarily HotKeys.js or Mousetrap. To make matters worse, three different events are associated with a single button press: keydown keypress keyup.
These keyboard events have several properties that can be used to identify which keys have been pressed. To do that, they listen to keyboard events that are emitted by your browser whenever your press a key. Web applications use JavaScript to process keyboard shortcuts.
Why is this baffling? Because the underlying technical issues are rather trivial! What baffles me is that the problem exists in apps used by millions of people every day, developed by gigantic corporations who pride themselves with having the best engineers in the world. It shouldn’t be an excuse that even some of the most popular apps do not get it right. It is possible to implement web application shortcuts so that they can be typed with any layout. I want to be clear, broken keyboard shortcuts are not a law of nature. In the case of Notion and Google Drive/Docs/Sheets, I was already aware simply because I use these applications myself. Then I googled and found complaints for most of these apps. I used Ke圜ombiner’s shortcut search to find all applications that use the US /-key in their shortcuts. for Google Sheets, Google Drive, and Google Docs.įinding all these applications with broken shortcut handling was very easy. For some reason, Google manages to handle international layouts correctly in Gmail, but fails to do so in any of its other applications. We are at a point where it is easy to find users complaining about this for almost any popular web application.Īn interesting example are Google’s apps. But rest assured, they are not new and I am not the only one who is affected. If you use a US layout, you might be surprised to hear about these problems. Similarly painful is when Electron apps use for navigating backwards and forwards. For example, on my German layout, / is produced via Shift+ 7. Adding modifiers to produce this key with your layout rarely helps. Unfortunately, there is no /-key on most international layouts. A very common shortcut is / for accessing search functionality. This is most annoying when the most important keyboard shortcuts are inaccessible. However, web applications are becoming increasingly complex, and they are rapidly replacing desktop applications, making this problem bigger by the day. The problem I am talking about is so incredibly omnipresent that most international users are just used to the fact that they cannot type a good portion of a given web application’s keyboard shortcuts on their keyboards. So, the arguments in this article probably apply to half of your installed apps as well. However, with the rise of Electron apps, web technologies are ever-present on the desktop as well. The behavior on desktop apps is often different.
0 kommentar(er)
