91–100 of 145 posts
Earlier quoted context omitted.
CTRL+L works for that too on Chromium / Firefox.
Not if you choose to have separate URL and search bars. In that case, Ctrl-L goes to the URL bar, and Ctrl-K goes to the search bar.
Sidenote: please don't hijack CTRL+F on webpages, thanks. Sincerely, the world.
Very nice! Hopefully Firefox developers have the bandwidth to implement this as well, and not let Google Chrome have this feature as an "embrace and extend" differentiator. As for MS-Edge, well I guess it must be funny for Microsoft to see they're getting a taste of their own sweet old medicine...
> As for MS-Edge, well I guess it must be funny for Microsoft to see they're getting a taste of their own sweet old medicine... Can you elaborate on this a bit?
And also that they believe that adding features like this to browsers is bad behavior in the first place. If that were the case and people abided by the "do nothing until the W3C acts" rule we'd probably all be using IE6-level browsers still.
/path/to/file:/from.*to
It pains me to see the web having strayed so far from its focus on interlinking. It's easy to make a parallel when on one side device makers have taken control back by removing access to files and putting applications first (this is the only model on mobile), to the point that those makers have enormous control over apps' existence, and the web where applications are now the only way to access content, to the point that content may or may not available if the right API exists.
Is it just me or whenever I open a link with a text fragment, the page is loaded just fine but it takes one or two seconds to actually scroll down to the highlighted text? Usually in Chrome and when visiting sites that are not 100% pure text (e.g., bloated Confluence docs)
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
Not if you choose to have separate URL and search bars. In that case, Ctrl-L goes to the URL bar, and Ctrl-K goes to the search bar.
Honest question, what's the use case for separate url and search bars?
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.
Earlier quoted context omitted.
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.
You _know_ somebody will be thinking about hijacking CTRL+F with this.
The thing I really hoped this "new" version would account for is when text changes and having links survive minor edits/changes. Perhaps I missed it and it does.
- https://github.com/NYTimes/Emphasis
- https://open.nytimes.com/emphasis-update-and-source-6ffac5e6... (2011)
Super unintuitive that the HTTP header a site can set, to disable this, is: Document-Policy: force-load-at-top
Does that disable the highlighting too or just the auto-scroll behavior?