Keyboards and web apps, my post/rant for the year
pb.co.za
pb.co.za
no, your re-implementation of existing browser feature is not better or even wanted.
This is entirely unreasonable. Imagine Google docs not being able to offer a shortcut to enable bold formatting, for example. Terrible experience.
Browser search only searches visible text in the DOM. For performance reasons the whole page might not be loaded into the DOM. This means the default browser search will provide incomplete results.
Forcing a request what could be done locally is bad design.
The dedicated search field is for searching my websites and the result would be a list of my pages that contain the search term. Ctrl-F jumps to the location of the search term on the page I'm already at.
The content you can find wih the browser search still doesn't do d the text on another page. A custom search could including a jump to the page.
If I specifically want to search the entire corpus of data on an infinitely-scrolling site, I will use its search function intentionally, since that is a semantically different action.
Individual site config is located here: application menu bar > "Tools" > "Page Info" > "Permissions" tab > "Override keyboard shortcuts"
I have found allowing overrides is unfortunately the least annoying of two bad options. But I still get unreasonably annoyed when web apps steal Ctrl-K which I use constantly.
This is absolutely infuriating, and the crux of it all is that I can't even edit the code that is taking focus and hijacking shortcuts! The goggles do nothing!
You can remove the shortcuts pretty easily with a userscript, see lines ~410-440 here for inspiration: https://github.com/tridactyl/tridactyl/blob/2eaba7e4ceec6de5...
Non-web apps are subject web technology specifications.
I absolutely sympathize with webpages disabling search features and so on, but I'm not sure why exactly. Pointing to app implementation doesn't seem quite right, if that makes sense.
As an example, you can't make a web app that controls display brightness.* It has everything to do with the fact that it's a web app. Web apps are built on web stuff, and web stuff provides no way to do it.
So it is with keyboard events.
* As far as I know, this is true. Maybe there's some new experimental spec or something? But you get the point.
https://developer.mozilla.org/en-US/docs/Web/API
Oh and by the way the screen brightness probably can be adjusted using the USB APIs if someone bothered to port over drivers for the most common keyboards.
At least all major browsers alert the user to choose if the web app can use these APIs unlike native apps.
Not sure what usb has to do with display brightness.
No shortcuts = cumbersome ⇏shortcuts = easy to use
For English input, being able to submit comments/chats with the enter key is a feature, but for Japanese (and maybe Chinese?) users it's a bug.
In Japanese the enter key is used multiple times to select from multiple possible characters while composing a sentence—it's just how Japanese input works. If an app submits when enter is pressed, it's very difficult to finish typing even a single sentence. Often the only solution is to compose text elsewhere and then copy/paste.
There is a solution: check the keyboard event isComposing (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...) property (alternatively, oncompositionstart and oncompositionend) and only submit if false.
Also… “onKeyPress” gives you names for most non-letter key presses.
For example, Reddit's rich text editor is broken for me. I cannot type an "é" in it - unless I switch to the manual Markdown mode. Is it annoying? Absolutely. But it only bothers me once every few days and there is a workaround, so whatever.
Website authors could specify a list of [name, callback, defaultKey] and each browser could implement an interface to change the binding locally.
There could be a button right in the address bar for both discovering them and changing them.
I honestly think it's just lack of awareness. I know it's partly because we warned against jacking native behavior, I think that probably scared people off shortcuts on the web early on. Now we have really complex web apps, but shortcuts are still not being thought about.
Reminds me of the president of a software house that wrote inventory software for large commercial warehouses. One of his customers required "Box ID", an essential capability that not only tells you how many we own, but exactly which boxes they are in. Everyone has it today.
These people attempted to satisfy this customer, but after a year and nothing to ship (it's not that hard!), they backed out and cried, "We'll never do Box ID again!"
I wonder what that guy is doing today.
And I wonder what OP will be doing tomorrow.
There are 2 hard problems in computer science: cache invalidation, naming things, off-by-1 errors, and all of the above.
E.g. Outlook Web hijacks CMD+R on my Macbook, of all things.
Wouldn't want to miss CTRL/CMD+K in some web apps though.
I wish there was some sort of universal agreement or API for what short cuts should do functionally.
I think this is a normal (and unhealthy) consequence of the JS browser APIs keeping expandong. A sort of Greenspuns Tenth Rule Of Programming that happened on the web platform.
I am not sure there is a cure. Every successful platform would have been bound to eventually become that.
That being said, same issue happens, albeit to a lesser degree, with desktop apps where occasionally the DE/WM shortcuts conflict with some applications shortcuts.
With this I'm able to use Ctrl+w normally in the Gitpod terminal, so this might work for the one in AWS as well.
I even understand why in some cases it’s necessary to provide custom search. For example to implement search over lazy loaded content which hasn’t yet loaded. But it never works as expected, even when it’s done well.
The web is far too hostile of a place to allow exposure of a robust API to it.
This is basically impossible, because the key matrix -> letter translation can be done in multiple places (in the keyboard firmware, in the OS, etc.). Hilariously, sometimes your keyboard firmware has to be aware of the OS translation; you cannot send a & keypress event over USB, so you have to send "shift + 7" if you want a key that generates that input. Because of all this, application developers have to add a "key binding preferences" page to their application. There is absolutely no way they can target a certain physical location on your keyboard.
None of this is specific to Javascript, of course. This is all about protocols and the OS.
As someone who just is getting into custom keyboards, this is one really ugly wart in the whole stack. imho ideally keyboard would just send individual scancodes and the host would manage all the key layout stuff. But making fully custom layouts complete with custom modifiers is afaik pretty much impossible with Windows/Mac/mobiles, and even on Linux its bit of a pain. So it ends up easier for keyboard to pretend to be a standard keyboard and have macros to send complex scancode sequences and then just have standard US qwerty layout on host side. Which kinda works until you want to input stuff that is not on the standard US layout at which point you need some different layout on the host, and then you need to remap the keyboard so that it is in sync with the layout. And then you need to sync these configurations across different computers and operating systems.
Sometimes standardization is great, but sometimes it hides all sorts of pitfalls that you'll stumble upon once you actually want to step outside the standard solutions.
There is no 1:1 keyboard position -> letter mapping, nor is there a 1:1 letter -> keyboard position mapping. This means something like "detect a press and hold of whatever key results in the input 'w'" is impossible. You can detect an "input" event for it, but there is no guarantee that there will be a "keydown" or "keyup" event. Similarly, you can't have something like "show the label on the key which is normally labelled 'w' on a Qwerty keyboard". It is not guaranteed to have a character associated with it.
Technically nothing is stopping you from creating shortcuts, but you are going to have an awfully hard time creating them in a way which works for all users.