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.
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-...
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.
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.
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?
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.
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.
I'm not complaining. What I'm trying to highlight is, as it says on the caniuse.com page, this feature has "Limited availability across major browsers", and that is to be expected and accepted.
If you're thinking of promoting use of this non-standard feature, consider how many people it _doesn't_ work for, rather than thinking "oh and yes even Firefox (asoftendaysagoandonlythedesktopmainlinereleasenottheesrormobileversion) so I'll rush out and proseletyze this amazing feature that clearly everyone can use"
As an alternative, all browsers the traditional scrolling to named element using a URL fragment, e.g. https://en.wikipedia.org/wiki/URI#Syntax goes to the "Syntax" section of the page. While the reason of text fragments it to allow for similar linking where there isn't an element with an id, most pages with non-changing text tend also to have non-changing layout and element ids.
If you generate links that include and depend on #:~:text= to make sense, accept that it will confuse users whose browsers do not support it. They will be linked to the top of the document and no text will be highlighted. Consider not only linking, but also quoting what you wanted to be highlighted, e.g.
John says <a href="https://example.com/#:~:text=I%20dislike%20this">he dislikes it</a>:
<blockquote cite="https://example.com/">
Down with this sort of thing. <em>I dislike this</em> and can't abide it.
</blockquote>
Browser support isn’t about what version you personally decide to run, it’s about what version your users are running. What Firefox ESR supports is the relevant factor here.
> Be honest and admit
Can you make your point without accusing people of dishonesty?
> Can you make your point without accusing people of dishonesty?
I was just returning the favor to amiga386 to make them see this is not a normal form of communication. They lead with
> 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.
When I think they meant to say support for most users isn't there until next year.
Because all major browsers have support already now in the current version.
> When I think they meant to say support for most users isn't there until next year.
They did say that though:
> full, reliable support
“Reliable” in the context of browser support means widely supported in the browser versions people actually use – i.e. web developers can rely upon it being there. Something that is only available in a browser version released last week is not “reliable” in the sense of browser support.
But Firefox supports it. Firefox developers can't do anything else to improve the support. There's no reason to suspect this feature is not implemented in a reliable way.
The onus is now on users that use Firefox. You're right that many Firefox users don't run the newest version, and you can't in general rely on a Firefox user having a browser new enough to support this feature.
Maybe this is a pedantic distinction, but it feels weird to say "Firefox doesn't support X" to mean "Old version of firefox, that some people use, doesn't support X"
> There's no reason to suspect this feature is not implemented in a reliable way.
As I said in my earlier reply, that is not what “reliable” is referring to in the context of browser support. “Reliable” means “We can rely upon our users having it available in their browser”.
This feature does not have reliable support and will not have reliable support until common browser support matrices – of which Firefox ESR is a part – includes support.
OP was correct to say that browser support is unreliable and that Firefox ESR is the thing causing this and will continue to be until next year.
Are you a web developer? “Reliable browser support” is a very well-understood term of art.
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
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]
[1] https://github.com/mozilla/standards-positions/issues/194#is...
[2] https://github.com/mozilla/standards-positions/issues/194#is...
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1753933
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
That sounds annoying, even if the only work required was to press `Home`. Does this only happen with the featured snippets?
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:
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.
The world wide web has moved beyond documents to apps. With apps there is nothing left to interlink.
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).
See also hyperbole for emacs.
Super unintuitive that the HTTP header a site can set, to disable this, is:
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)
Does that disable the highlighting too or just the auto-scroll behavior?
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.
In Google Chrome select text, right click and click "copy link to highlight". It create a link with ~:text=
Also added to the next release for Firefox.
Also works in Orion, though it's labeled "Copy link to selection."
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.
[1] https://blog.paulbiggar.com/i-cant-sleep/
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.
- https://github.com/NYTimes/Emphasis
- https://open.nytimes.com/emphasis-update-and-source-6ffac5e6... (2011)
There's no such thing as "text changes". Only publishers lying about URLs and response bodies. This should stop.
Wow, this is interesting to see. Thanks for sharing. This was long before any standardization in this area
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-...
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.
you could try and target a div to highlight
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.
…why not put a css-selector in the link?
Every time I run across this I think about how useful it is, then forget it exists and never actually use it.
I've noticed that Google inserts this into result links sometimes, taking you to the relevant part of the page.
https://www.w3.org/TR/xptr-framework/
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.
<https://www.w3.org/annotation/>
I always wished something to point at typos in websites... thanks for that
E.g. https://alfy.blog/2024/10/19/linking-directly-to-web-page-co...
Thank you for the highlight, I will fix it so that your link no longer work
Is there a specified / supported way to include other parameters in the URI fragment if the fragment part of the URI starts with :~:text=?
w3c/web-annotation#442: "Selector JSON to IRI/URI Mapping: supporting compound fragments so that SPAs work" (2019): https://github.com/w3c/web-annotation/issues/442WICG/scroll-to-text-fragment#4: "Integration with W3C Web Annotations" (2019): https://github.com/WICG/scroll-to-text-fragment/issues/4#iss...
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?
Some sites do: The Wayback Machine changes the url if you change the selection.
> Text fragments are currently supported in all the browsers.
All meaning all the browsers listed in the linked table. These may be the major browsers, but not all of them.
Brave has this feature disable due to (rather minor, imho) privacy concerns.
https://github.com/WICG/scroll-to-text-fragment/issues/76
https://github.com/brave/brave-browser/issues/17994
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.
By market share, that table contains all the major browsers and more.
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?)
https://addons.mozilla.org/firefox/addon/text-fragment/
Support for the feature itself was only added in a very recent mainline firefox release. Like, less than one or two months ago.
https://addons.mozilla.org/en-US/firefox/addon/link-to-text-... extension for creating links
According to the post
> If you’re using Chrome, simply highlight some text, right-click, and you’ll find the “Copy link to highlight” option in the context menu
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=
Using text fragments is particularly useful when you don't control the page you're linking to and it doesn't have a good anchor to link to.
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.
Why can't the browser do all of that when you create a link to the selection?
It would have to, kind of my point. Either the browser or someone would have to create some javascript widget to do it.
It does. Try it.
I didn’t say it didn’t.
> It would have to
I wonder how that can be leveraged for SEO
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...
It was added to Firefox in 131, released a few weeks ago: https://www.mozilla.org/en-US/firefox/131.0/releasenotes/
And "add useful UX features that people want" is not "EEE", especially when there's a standard doc and test suite for it.
FYI, the "standard doc" isn't in any sense standardised yet
https://wicg.github.io/scroll-to-text-fragment/
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
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?
No, I would say you were describing WHATWG and their HTML5 specification (now called the HTML Living Standard)
https://en.wikipedia.org/wiki/WHATWG
The Web Platform Incubator Community Group is "a lightweight venue for proposing and discussing new web platform features" within the W3C
https://www.w3.org/community/wicg
Oh yeah I got that mixed up. Thanks.
Edge does have a "Copy link to highlight" option in its context menu.
And on mobile, it is called “create link”
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.
The feature "seems to work on Firefox" if you're using the version of Firefox released 10 days ago [0]
It's not implemented in Firefox ESR and won't be until June 2025 [1]
[0] https://caniuse.com/url-scroll-to-text-fragment
[1] https://whattrainisitnow.com/calendar/
Which is to say, that it work on Firefox.
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.
I'm not complaining. What I'm trying to highlight is, as it says on the caniuse.com page, this feature has "Limited availability across major browsers", and that is to be expected and accepted.
If you're thinking of promoting use of this non-standard feature, consider how many people it _doesn't_ work for, rather than thinking "oh and yes even Firefox (asoftendaysagoandonlythedesktopmainlinereleasenottheesrormobileversion) so I'll rush out and proseletyze this amazing feature that clearly everyone can use"
Is there an alternative? Do users with browser that don't have support have a worse experience when these links are used? I thought no...
As an alternative, all browsers the traditional scrolling to named element using a URL fragment, e.g. https://en.wikipedia.org/wiki/URI#Syntax goes to the "Syntax" section of the page. While the reason of text fragments it to allow for similar linking where there isn't an element with an id, most pages with non-changing text tend also to have non-changing layout and element ids.
If you generate links that include and depend on #:~:text= to make sense, accept that it will confuse users whose browsers do not support it. They will be linked to the top of the document and no text will be highlighted. Consider not only linking, but also quoting what you wanted to be highlighted, e.g.
> If you decide to not update
Browser support isn’t about what version you personally decide to run, it’s about what version your users are running. What Firefox ESR supports is the relevant factor here.
> Be honest and admit
Can you make your point without accusing people of dishonesty?
> Can you make your point without accusing people of dishonesty?
I was just returning the favor to amiga386 to make them see this is not a normal form of communication. They lead with
> 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.
When I think they meant to say support for most users isn't there until next year. Because all major browsers have support already now in the current version.
> When I think they meant to say support for most users isn't there until next year.
They did say that though:
> full, reliable support
“Reliable” in the context of browser support means widely supported in the browser versions people actually use – i.e. web developers can rely upon it being there. Something that is only available in a browser version released last week is not “reliable” in the sense of browser support.
But Firefox supports it. Firefox developers can't do anything else to improve the support. There's no reason to suspect this feature is not implemented in a reliable way.
The onus is now on users that use Firefox. You're right that many Firefox users don't run the newest version, and you can't in general rely on a Firefox user having a browser new enough to support this feature.
Maybe this is a pedantic distinction, but it feels weird to say "Firefox doesn't support X" to mean "Old version of firefox, that some people use, doesn't support X"
> There's no reason to suspect this feature is not implemented in a reliable way.
As I said in my earlier reply, that is not what “reliable” is referring to in the context of browser support. “Reliable” means “We can rely upon our users having it available in their browser”.
This feature does not have reliable support and will not have reliable support until common browser support matrices – of which Firefox ESR is a part – includes support.
OP was correct to say that browser support is unreliable and that Firefox ESR is the thing causing this and will continue to be until next year.
Are you a web developer? “Reliable browser support” is a very well-understood term of art.
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".
> 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?
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.
Something with internet explorer but I'm not old enough to know what exactly.
Copy link to highlight is best feature.
Can you disable it in firefox?
shift+i -> "permissions" -> disable "override keyboard shortcuts"
Huh? This post isn’t about overriding Ctrl-F.
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)
It is very annoying, yes.
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.
Sidenote: please don't hijack CTRL+F on webpages, thanks. Sincerely, the world.
[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!
Ctrl-F should search the loaded page using the browser's search settings so that the user can have a consistent interface.
If sites choose not to load the page all at once they can provide another search bar with a different experience. But that's not the Ctrl-F search.
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.
Interesting that this is the top comment at the time I'm reading this, while the article isn't at all about hijacking CTRL+F.
That's why it's prefaced with "sidenote"
Please don't hijack HN threads with unrelated gripes about the modern the web and please don't pretend to speak for the world.
I have to agree.
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.
Unrelated? CTRL+F is literally in the title...
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.
I appreciate the effort to retcon your comment, but I'm afraid it creates too many plot holes for me to buy it.
It is. But the article doesn't talk about hijacking its behaviour.
I've seen that on pages with text editors that don't load all the text or where search is expanded with more features, like for example on Github.
In these cases I usually click outside the editor and then control+f works as usual.
If not, you can also try F3, and if that's hijacked too browsers usually have a shortcut to "find in page" in the hamburguer/three-dots menu
And `/` neither, while you're at it (I'm looking at you, GitHub).
They have a (broken) setting under the accessibility settings which disables all the character key hijacking.
https://github.com/settings/accessibility
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.
But even then I shouldn't need to do it for every website that does this.
Found the vimmer
True, but `/` is also a shortcut for quick find in Firefox.
And ' searches through the links only. Find a link, press enter (or shift+enter) and you don't have to touch the mouse or install vimium and friends.
Or just anyone who uses `more` or `less` or almost any other pager.
Indeed :)
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.
Would really appreciate hearing others’ thoughts!
> What would be a better approach?
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.
[1]: https://github.com/settings/accessibility
> 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.
Maybe you could find shortcuts that aren't used by major browsers. They should be documented somewhere.
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.
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.
Honest question, what's the use case for separate url and search bars?
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.
And F6 is one of them, but I can't remember which one.
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.)
All the nerds trained their friends and family on Chrome. We did it to ourselves.
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