Today I learned that Firefox finally implemented these! They don't mention this in the article, but that's new this month—for the longest time Chrome supported it but it isn't in the standard and Firefox didn't include it. Safari got it 2 years later, but Firefox held out for a while.
I'm normally not a fan of Chrome unilaterally adding something to the platform, but this has been a long time coming.
I was surprised too, cause initially they had some issues with the proposal [1], resolved it few years later [2], and finally implemented it since last year [3]
In all honesty, I've hated this feature with a passion ever since it appeared.
If it was simply a matter of being used in the way outlined in the article, when someone creates a a link that references a particular piece of text, then fine, someone has deliberated intended the link to behave like that.
And then we have the lovely folk at Google search... who think it's fun to drag my attention off to a random part of a page that isn't where I want to be, forcing me to right-click, remove annotation and scroll back up to the top of the page.
That doesn't seem like a massive hardship, but it gets quite frustrating when multiplied over the many searches done in a day/week/month.
Isn't the reason it highlights that from search because that was your search term? That's what I've seen, in which case I prefer that it does draw my attention to that string
Sounds like your problem is with a Google product more so that the browser feature itself. I for one can't wait to start using these kinds of deep links. I love when websites have "copy link to header" buttons, but even when they do I often want to link to a particular sub-paragraph or sentence as a citation... and now I can!
Unsurprisingly this is something you could do in Plan 9:
/path/to/file:/from.*to
opens the file and sets the selection to the range of text between "from" and "to". Bonus: you can use regular expressions.
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.
vim users may be pleased to know that this can be done when vim is invoked from the command line, via the +/{pat} option. Sadly doesn't work for gF (yet).
Unfortunately, not supported away from chromium derived browsers ATM: https://caniuse.com/document-policy (though given current market shares that sill means the majority of your user base is likely to have support)
I think we're a long way from standardisation just now. So the behavior of the header is verging on the undefined territory. It might do something. It might even order a grape soda. Hopefully it does what you want. It might not.
Programmatically what can a developer do with this?
I see that there is a method and an object to see if its enabled or not. And there is a way to get the whole fragment which can be parsed.
Are there methods to see whether some text in the fragment was actually highlighted or not? Are there methods to programmatically select text?
Could there be a way to, for example, draw a rectangle around the highlighted section, to get the coordinates of the text, to read out the selected text, to store what words people select and link to etc
Maybe it's an external link about headline news and the news title got changed by the editor. Maybe the developer may want to change the selection to the edited title so the user isn't surprised. Maybe its a multi lingual blog post and the user links using another language... etc etc
Since you have access to the URL fragment in JS, you should be able to do any of that manually even if there isn't a special API to use. The easiest thing to do would be to check for this specially-crafted fragment in the URL and store it.
I think though that this is a pretty niche feature though, so it's unlikely to be a big source of data. In my experience, the median sophistication web user has discovered that the browser's Back button exists and can Open in New Tab. Bookmarks, zoom, ctrl-F are all too confusing. A feature that requires right-clicking may as well be black magic to most people.
I use these for footnotes, eg in [1] which had a lot of footnotes. Ghost and other blogs don't support footnoting well afaict. Sometimes I miss restructured text, which did this quite well, markdown alas does not.
I built something like this for The New York Times and it was one of the more fun projects I did there.
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.
New revisions are issued, but the text changes no more in those instance than it does when a publisher releases an update to a print work originally published in 1985 with a second edition. The text of the second edition might differ from the first edition, but the first edition's text doesn't change, and the first edition is still the first edition (instead of the first and second editions being synonymous). And the publishers of the print editions could try lying about the identity of these two distinct manifestations the way that online publishers lie about the identities of the works they publish, but no amount of lying about it makes the lie true.
It would be nice to have similar feature like this, but to highlight rectangle (instead of text) on the page to focus viewer on some specific area. I send screenshots with highlight quite often.
Pretty difficult to specify a rectangular region within reflowable content. It would need to be anchored by element edges, but if the algorithm chooses bad anchor elements or they reflow in weird ways (a layout that goes from horizontal to vertical on small screens, for instance), everything breaks.
or every document on the web may have hierarchical semantic structure, so you can link/refer to a heading in any depth. eg #1 → first chapter; #1.2 → first chapter second heading; #1.2.1 → first chapter second heading first paragraph; #1.2.1.5 → first chapter second heading first paragraph 5th sentence. it won't neccessary be chapter-heading-paragraph-sentence 4-fold structure - just wanted to illustrate in conventional language -, but any level of structure.
Looks like Firefox is lagging behind. It understands the url but there doesn't seem to be a way to create it from the UI. Chromium has "Copy link to highlight" in the right click/context menu but Firefox 131.0.3 doesn't. There is an add-on though: https://addons.mozilla.org/en-US/firefox/addon/link-to-text-...
I was thinking of that as well. I wonder what the world would look like if the whole XHTML angle would have been a success. While it certainly had its flaws, there were definitely some interesting ideas.
Besides XPointer and its precise addressing I used to be very fascinated about more generic link types. I don't remember the spec (was it XLink?) but there was one where source, target and the location where the link was specified were independent. A link could also have multiple ends.
So you could create a personal
document that linked a HN comment to two different sentences in a Wikipedia page for example.
That is an interesting issue (detect differing resource loading based on the document jump) that affects regular fragments as well, but the idea is that particularly sensitive pages would know not to have fragment targets in the page but couldn't prevent text fragments. The solution given (deterministic loading independent of jump target) seems like a good idea to work towards but meanwhile I agree it is a minor concern and pages should not avoid reasonable navigation due to this issue. Particularly since there are often other ways of getting the same information with the same type of network analysis.
I wonder whether it was a mistake to separate this feature from a standard selection.
I don't know how to design it separately. The default is that selections are blue and fragments are purple, but if you choose different colors for both, in line with your color scheme, how will people know which is which? I guess you can still choose different tones of blue and purple.
Why shouldn't selecting text automatically update the address?
This is the ultimate time saver feature when sharing. I built a web layer that does this, but goes further with multiple highlights, navigation, and rich inline communication with humans and AI, which is integrated with a web app to save, organize, and share with humans and AI. It’s https://www.kontxt.io
With a addon this is much more usable, not sure why there isn't a selection-to-text-fragment-link functionality builtin to Firefox...(same for other browsers?)
It’s really cool but it seems rather convoluted for the typical user. We should perhaps start making good use of the ID attribute and linking to that first before we start trying to use ~:text=
It's literally three clicks... Select text, right click, create link to selection.
I agree you should prefer IDs but they aren't always available, and often using them is very convoluted for users (how many are going to know how to use the element inspector, or even what an ID is?).
It's not difficult for you and me, sure. Try explaining you need to add a tilde, colon, the work text, equals sign then the text you want to the end of the URL.
You're missing that Chrome has this built in to the context menu. My dad has been sending me links like this for years now, they just haven't worked for me until this month because I use Firefox.
I'm assuming Firefox has this context menu feature on the road map as well, though I suspect it will be a long time before Safari adds it just because Apple.
The average person doesn't even understand a URL at all—as far as they're concerned they're generated by computers for computers and are copied around with little regard for what the various components mean. This feature doesn't change that, it just gives a new way of creating a URL that does something slightly different.
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...
Isn't Web Platform Incubator Community Group the group browsers makers formed because the W3C was being too slow and then largely overtook the W3C in terms of relevance?
This feature seems to work on Firefox as far as I can tell. It used to be one of those Chrome APIs, but now every browser but Safari seems to support them completely. I'm sure the Safari team can quickly implement the last bit of Javascript API when they get the opportunity to.
I'm running Firefox right now. It doesn't work. I use Firefox ESR version. Many people do. Many people have also not installed updates released a mere 10 days ago.
Be honest and admit that full, reliable support for this feature among all the main browsers is not going to be there until at least next year.
What? It is there already in Firefox latest version. Do you mean it will take that long until the majority of users have it?
If you decide to not update or use a version that is updated less often, that is not the fault of the people working on the software.
Be honest and admit that you are knowingly using a Firefox version that gets major updates only every 52 weeks and still complain about not getting a released feature.
It works just fine on Firefox. The things that seems to be Chrome-only is the "select some text, right click to get direct link" bit, and the "link to text that is hidden".
I think GP mistakenly believes that Chrome implemented this in its proprietary part instead of getting it from Chromium which was the actual case. In reality I think the feature appeared in both browsers at roughly the same time as a result.
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.
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)
Because of this bloat in Confluence, we actually just use it for editing and serve the content in a more lightweight way using the API and our own templates.
Yeah, even linking to a heading using its HTML ID (part of the pure HTML browser spec) was broken in Confluence for a while due to its fancy reimplementation of the concept of "serving a basic HTML document" in flashy React-y technologies. Though it works now.
[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.
This also works perfectly in Microsoft Edge and has for a long time. Pointing this out because the post makes several references to things being exclusive to Chrome, when really it's probably just Chromium.
(I'm still puzzled why so many more people choose to use a browser distributed by the world's largest ad network over one with all the same features plus a few nice add-ons, made by a software company.)
As of a few years ago, independent tests of telemetry back to Bing, immutable hardware-derived identification, and add-on security of the Edge store were not good.
I guess I'm not convinced Microsoft is serious enough about monetizing my data and attention the way Google is. I'm assuming (generously, to be fair) that Microsoft mainly wants to optimize their software rather than use the data to maximize the effectiveness of their ad business, which seems hobby-level to me.
> immutable hardware-derived identification,
Is this in the telemetry data? Not in headers, right? Just curious to learn more
But the zeitgeist I’ve seen in 2024 is that Edge and Chrome collect the data they want, plus the data each other is collecting. Tabs, history, etc. Google appears to be more careful, speculatively because it would be easier to prove anti-trust if Google blocked Microsoft’s collecting.
I'm normally not a fan of Chrome unilaterally adding something to the platform, but this has been a long time coming.