[for those just reading the comments having not read TFA: it isn't talking about changing default find behaviour within a page, but the feature to specify text to scroll to and highlight within a link URL so the user doesn't need to ctrl-F when you refer to a small part of a larger page]
Sometimes they "need" to, because rather than load 100kB of text, they'll chunk 100kB of text over ten JSON requests and searching requires backend intervention. If you make every web page an app, the browser doesn't work right anymore so you force yourself to build a browser within a browser!
Even if it's for that, it's infuriating, and a terrible pattern. Just as I expect CTRL+click to open in a new tab, there are some interactions that should be left alone; it's annoying to me that they even can be overridden.
Small tip, and I know it doesn't make it much better, but in few cases I've seen this done (Discourse is the main culprit and it's widely used) pressing Ctrl+F a second time will go to the normal browser "Search in this page" function. Still annoying, but manageable.
Normally I think related side notes are fine. Heck, I’m guilty myself. But nowadays I always open the link first to make sure it's the right topic and to make sure it’s not addressed in the article. Often leads to a better response as well.
Yes, we know scroll-jacking or any other override of browser behavior is extremely disliked here.
And only in the title. It doesn't mention the keyboard shortcut once in the body because it's not about keyboard shortcuts, it's about "linking directly to web page content".
In addition to unrelated gripes, it's generally considered bad practice to comment only based on the title.
But for whatever reason this only seems to work temporarily (if it is already toggled off for you, you need to enable it again, save preferences, then toggle it off, and save preferences) and then it does not hijack '/' for a few minutes.
Hijacking CTRL+K sucks, too! It's the shortcut used to focus the browser search input in Firefox, but the industry has seemingly decided it's a great way to launch a command palette.
I recently implemented this, and the users loved it, though I was disappointed to hear it may have frustrated a usually silent group.
I'm open to feedback! What would be a better approach? Please don’t just suggest “no custom shortcuts for any web app”—people spend 60-70% of their workday using the UI components my team maintains. While random sites hijacking shortcuts is definitely frustrating, in our case, the pros seem to outweigh the cons.
Maybe allowing users to disable or customize shortcuts could be a solution? Or would that be over-engineering?
Honestly, I think the web platform could use a standard API for defining shortcuts, with browsers providing a UI to manage or disable them. Maybe I'm still over-engineering here.
I think Github handled this well by letting you choose between a few canned shortcuts, or disabling the feature altogether [1]. Since I seldom print, I opted to bind the command palette to "CTRL + P"
> Honestly, I think the web platform could use a standard API for defining shortcuts, with browsers providing a UI to manage or disable them. Maybe I'm still over-engineering here.
I'd agree with this sentiment. It's hard, but an obvious (IMO) pain point that has numerous sites reinventing the wheel and needing to introduce some state to save user preferences.
> I was disappointed to hear it may have frustrated a usually silent group.
This group isn't usually silent (far from it), they're just not usually your users.
If you're building a web app a la Notion, Figma, Google Docs, Slack, or anything similar: just ignore the "the web should just be documents that strictly use the platform" complaints. Ensure you build in the required accessibility hooks (since those don't come natively to most custom work), but your users will thank you for accommodating their specific needs better than the platform does.
If you're building a web page that mostly presents information... yeah, maybe listen to the people here.
The main thing you're seeing here is that there's a subset of developers who haven't ever really liked the idea that the web became the primary means of deploying applications.
The "press again to fall back to the browser's key binding" solution many sites use for ^F isn't perfect, and won't work for all scenarios, but it definitely helps.
> Honestly, I think the web platform could use a standard API for defining shortcuts, with browsers providing a UI to manage or disable them. Maybe I'm still over-engineering here.
I think this is really cool and would also allow some interesting features...
- Easier using random input devices. Game engines like Unity with their newest input manager abstracts everything away. Bind inputs not only to standard navigation actions but also app-defined shortcuts.
- Custom UI provided by the browser based on available shortcuts. PCs could get a quick actions bar and phones could have a shortcut drop-down menu exposing functionality.
- If there is an API for enabling/disabling shortcuts the browser can provide context-sensitive shortcut suggestions like some of the profession creation tools like Fusion360 [iirc] where available shortcuts are shown in the status bar.
At least in Firefox there is still a difference even if you don't have a separate search bar. Ctrl-K goes to the URL bar as a search in your default search engine while Ctrl-L goes to the URL bar in whatever mode it currently is in. This mostly matters if you disable searching by default in the URL bar but still search from the URL bar, although there is also a visual indication that you are searching with Ctrl-K in the default configuration.
I keep them separate for two reasons: one privacy, and another preference:
1. If I'm interacting with the URL/address input, I'm either entering a full URL, or searching through my local history to jump to a previously-visited page (or, in Firefox, a tab I may have open on another device). I don't want that shipped off to my search provider for autocomplete suggestions.
2. If I'm interacting with the search input, I want autocomplete suggestions. Additionally, because it retains the value of the last term I searched for, I can use it as a shortcut to jump back to the results if I no longer have the tab handy.
It prevents you from leaking data in cases where you like live search suggestions (like completions from your search engine based on partial text entered) but didn't want your search engine recording all the URLs you visit outside of search.
Sometimes it's fine if a page is lazy-loading content, in which the browser's CTRL+F does not work because the text isn't all in the DOM at that moment.
Maybe this is a hot take then, but I think most sites I've seen that do this, are surprisingly good at doing their One Job correctly such that I haven't resented it the way I resent things like overridden context menus, links that are not really links, etc.
e.g. GitHub. If I'm on a source file and I hit Ctrl-F, yes, in fact I do want to search the source code and not GitHub's UI -- and their search bar for that purpose is delightfully simple and not distractingly different than the normal search I expected to see when I hit that key.
What would make me rage throw my computer through a window would be if I hit Ctrl-F and it loaded a full-screen modal which showed a search results page of result snippets or something. So I'm impressed with the restraint shown by the front-end developers (or their "UX designer" taskmasters) in this case.