Is there a single webapp with keyboard navigation that is even remotely reliable, useful, user-friendly and discoverable?
After almost 20 years of Web2.0 I am beginning to think .... no? Maybe it's just a somehow legitimately hard problem.
GMail: close, no cigar.
Google Docs: steals control-F
Wordle: nope, but I forget why
Mastodon: hah hah no
Reddit: oh you sweet summer child
@jasonp I'm not sure how to parse "Google Docs steals control-F." It maps it to "find in doc," which is necessary because it must delegate that operation to the backend (the frontend doesn't have the whole doc resident in memory to search it; really *can't* since Docs can be an arbitrary size well beyond what's practical for most browser clients).
What do you want to ctrl-F that ctrl-F isn't ctrl-F'ing in Docs?
@mtomczak yep, mapping to "find in doc" is exactly what I mean.
Your explanation of why it works that way explains why it often can't find strings that I know exist in a doc and want to zap to (as well as being even slower than the browswer control-F, which is actually kind of impressive).
If a webapp is going to intercept common browser functions, it needs to implement the functionality seamlessly, or just give up and expose the underlying limitation so users can route around it.
@jasonp Oh, I think I follow. Your frustration is that if somebody has ctrl-F too soon they get the browser find instead of the hooked find?
That's a real problem and I don't think it's one that can be changed without a change to the browser API itself... You'd have to guarantee the relevant hook is installed before any user interaction events are processed, which means you need a way to gate user interaction on a certain minimum of the page being loaded. I don't think any aspect of the RFCs gates that and it will be necessary.
Good thing to work around is simple, obvious, and easily discovered while we wait for a better API.
Hm, that's *not* what I meant but now that you point it out, yes, that's the primary way that Docs stealing control-F presents a less-than-optimal experience.
If I had my druthers it wouldn't be possible for code running in the browser to intercept control-F and friends _at all_.
An example: this 6-letter wordle variant I play occasionally: https://www.thewordfinder.com/6-letter-wordle/ . It steals *command-L* (in Chrome on my Mac). I honestly thought that wasn't possible.
@jasonp Oh, that would be suboptimal. Users expect control-F to mean find, and it would be rough on them to have to memorize some other key sequence to do finds when 'find' starts with 'f'.
Ideally, were I king of user interfaces and redesigning modern computers from scratch to be better platforms for the web ecosystem, I would split out the meta keys that acted as accelerators for the browser itself (and operating system, because the way I use things these days those are almost indistinguishable) and content of the web page. So you'd have a control key for browser operations and operating system operations and a "webmeta" key exclusively for keyboard acceleration inside of a web app. Can't quite retrofit it on the existing ecosystem because there's too much divergence among the dominant operating systems on what those meta keys do (Apple stole an entire meta key just to extend the keyboard). Google is almost in a position to try an experiment like this with Chrome OS; they'd have to devise an RFC establishing a new API for webmeta and clarify how a user agent takes advantage of it if it's lacking that key (two-pass could work... Have one control-something sequence mean "do a webmeta" and then the next key pressed is treated as webmeta-thatkey).
But it would be kind of cool if somebody took the lead on that, and I bet if a player is big as Google did, it wouldn't be too many years before the other browsers extended their input logic to support a webmeta, with keyboard developers not far behind.
