
Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page - kumaranvpl
https://www.chromestory.com/2019/02/chrome-scroll-to-text/
======
xg15
Technical question, apart from the (valid IMO) political arguments: Google's
idea to implement this is to append the text fragment to the URL in a
"#targetText" pseudo-query-argument in the URL fragment part. This sounds like
it would extremely easily break existing web pages who use the fragment part
for their own state.

In the blog post, there doesn't seem to be anything addressing this (or even
just specifying how Chrome would combine the "targetText" fragment with an
already existing fragment part)

Did they spend any thought on this?

Edit: Oh, right, the readme answers this:

> _Web pages could potentially be using the fragment to store parameters,
> e.g.[http://example.com/#name=test](http://example.com/#name=test). If sites
> are already using targetText in the URL fragment for their own purposes,
> this feature could break those sites._

> _We expect this usage to be exceedingly rare. It 's an abuse of the purpose
> of URL fragments and page arguments are typically encoded using the '?'
> character (e.g.
> [http://example.com?name=test](http://example.com?name=test)). Still, we may
> run an experiment to see if targetText is available enough to use as a
> reserved token._

We'll just completely change the commonly understand processing model of
fragment identifiers, but it'll be fine since we don't think anyone is using
them anyway...

No further questions...

~~~
bokan
Feature author here.

I'd like to first clarify that this is still in the super-early stage of
development; none of this is shipped or finalized yet. The feature hasn't even
requested approval to ship at which point these kinds of issues would be
brought up. We take web-compat very seriously. If this breaks even a small
percentage of pages, it won't ship. Part of the shipping process is ensuring
we have at least a draft spec (W3C,WHATWG) at least some support from other
vendors.

Sorry, the explainer text came off more dismissive than I intended. I wanted
to get something implemented so we could start experimenting and see how this
would work in the wild. #targetText= is a a first attempt at syntax, any
criticisms or data on how this might break would be appreciated.

From my (limited) understanding of how fragments are used like this today, the
way this would break a page is if the page itself was using "targetText=..."
and parsing the result. This is something we can and will measure and see if
we have a naming collision. For pages that use a "#var=name" type fragment, we
could append "&targetText=...".

I'm not tied to any particular syntax here so if I'm missing why this is a
monumentally bad idea, please file a bug on the GitHub repo:
[https://github.com/bokand/ScrollToTextFragment/issues](https://github.com/bokand/ScrollToTextFragment/issues)

~~~
creato
This is not rare at all, I use it almost every time I link to a wikipedia
article, for example:
[https://en.wikipedia.org/wiki/Newton%27s_method#Examples](https://en.wikipedia.org/wiki/Newton%27s_method#Examples)

That said, it seems easy to make this backwards compatible: if the existing
#blah syntax is a valid link, that should take precedence.

FWIW, I think there's way too much cynicism in this thread. My first reaction
on seeing the title was "cool! I would use that!".

edit: Hmm, I may have misunderstood the compatibility issue.

~~~
bokan
> That said, it seems easy to make this backwards compatible: if the existing
> #blah syntax is a valid link, that should take precedence.

That's indeed how it works. The majority of the compatibility concerns appear
to be with apps that a using _custom_ parsing of the fragment to perform app-
specific logic, which is a valid concern.

~~~
kiliancs
Angular 1 does this.

------
csarven
I would like to urge the browser developers/makers to adopt existing proposals
which came through open consensus which do precisely cover the same use cases
(and more!)

W3C Reference Note on Selectors and States: [https://www.w3.org/TR/selectors-
states/](https://www.w3.org/TR/selectors-states/)

It is part of the suite of specs that came through the W3C Web Annotation
Working Group:
[https://www.w3.org/annotation/](https://www.w3.org/annotation/)

More examples in W3C Note Embedding Web Annotations in HTML:
[https://www.w3.org/TR/annotation-html/](https://www.w3.org/TR/annotation-
html/)

Different kinds of Web resources can combine multiple selectors and states.
Here is a simple one using `TextQuoteSelector` handled by the
[https://dokie.li/](https://dokie.li/) clientside application:

[http://csarven.ca/dokieli-
rww#selector(type=TextQuoteSelecto...](http://csarven.ca/dokieli-
rww#selector\(type=TextQuoteSelector,prefix=ed%2C%20browser-
based%20authoring%20and%20,exact=annotation,suffix=%20platform%20with%20built-
in%20support%20\))

A screenshot/how-to:
[https://twitter.com/csarven/status/981924087843950595](https://twitter.com/csarven/status/981924087843950595)

~~~
ru999gol
I'm so glad that google just sometimes ignores W3C's horrible design-by-
committe nonsense. Its the same reason XHTML failed.

    
    
        #selector(type=TextQuoteSelector,exact=foo)
    

vs.

    
    
        #targetText=foo
    

/edited to be a more fair comparison

~~~
csarven
I urge you to dig a little deeper and see why things like `prefix`, `exact`,
`suffix` exists in that particular example:

[https://www.w3.org/TR/selectors-
states/#TextQuoteSelector_de...](https://www.w3.org/TR/selectors-
states/#TextQuoteSelector_def)

Please note that you've actually changed the example!

If you just want to include `exact` or "targetText", you can still do:

[http://csarven.ca/dokieli-
rww#selector(type=TextQuoteSelecto...](http://csarven.ca/dokieli-
rww#selector\(type=TextQuoteSelector,prefix=,exact=annotation,suffix=\))

or equivalent:

[http://csarven.ca/dokieli-
rww#selector(type=TextQuoteSelecto...](http://csarven.ca/dokieli-
rww#selector\(type=TextQuoteSelector,exact=annotation\))

but that selects all instances of the text "annotation" in the document. Which
is precisely why we need `prefix` and `suffix` to be able to identify the
actual selection that the user made.

So, here is the equivalent of your example:

[http://csarven.ca/dokieli-
rww#selector(type=TextQuoteSelecto...](http://csarven.ca/dokieli-
rww#selector\(type=TextQuoteSelector,exact=browser-
based%20authoring%20and%20annotation%20platform%20with%20built-in%20support\))

I hope that clarifies.

This is just tip of the iceberg! Let's stick to fair comparison and consider
extensibility.

~~~
crehn
Even with that in mind, the W3C spec adds unnecessarily verbose syntax fluff.

~~~
csarven
We can only compare what's on the table, ie. arbitrary text selection. The
targetText proposal doesn't necessarily result in a unique identifier that
deterministically corresponds to user's original selection. So, I'm not sure
if there is any point in discussing the syntactical differences on specificity
further at this point. Having said that, at the end of the day, it is going to
be the application that generates and uses the identifier.

Please have a closer into why we should be mindful of different use cases
here, especially those pertaining to different resource representations, ways
to "select", and factor in the state of the resource/representation at the
time of the selection. It is there for use. It doesn't mean that all possible
options needs to make its way into the identifier. This is important because
people are going to use these identifiers in documents, and preserving context
matters. Like I said earlier, the W3C Note has considered these, as well as
permitting the use of different (RFC) selectors for different media. Let's
reuse instead of NIH-FUD.

------
myfonj
Back in the days of yore, I've made a super simple userscript [1] that was
used in my close circles exactly for this purpose; basically is just

    
    
        window.find(document.location.hash.substring(1))
    

And yes, it was really convenient to exchange links without need to add "and
there search for %word%". I haven't probably seen any other use of window.find
[2] ever since.

[1] [http://userscripts-mirror.org/scripts/review/8356](http://userscripts-
mirror.org/scripts/review/8356) [2] [https://developer.mozilla.org/en-
US/docs/Web/API/Window/find](https://developer.mozilla.org/en-
US/docs/Web/API/Window/find)

~~~
muthdra
Cool, it's like it's exposing Ctrl+F.

------
gioele
Why aren't XPointer/XPath fragments used instead of yet another half-backed
reimplementation of the same concept?

XPointer and XPath have been ratified by the W3C in (...checks...) 2003. They
have since been revised, slimmed down and used in countless XML-based
applications and specs.

The cool thing about XPointer is that it is basically impossible that its
fragments are already used in the target document. No site would break if
XPointer were used.

Examples of XPointers:

* Pointer to _all_ the occurrences of "target text" anywhere in the page (goodbye JS-inserted <mark>)

#xpointer(string-range(// _, "target text"))

_ Pointer to all occurrences of "target text" in a <p> in the <main> article

#xpointer(string-range(//main//p,"target text"))

* Pointer to the second <h2> heading

#xpointer(//h2[2])

* Pointer to that specific bullet point that you want your colleague to change ASAP

#xpointer(//ul[7]/li[3])

* Abbreviated fall-back to XPath

#//ul[7]/li[3]

~~~
csarven
XPointer is one of options for a fragment selector in W3C Reference Note on
Selectors and States: [https://www.w3.org/TR/selectors-
states/](https://www.w3.org/TR/selectors-states/)

See also
[https://news.ycombinator.com/item?id=19169582](https://news.ycombinator.com/item?id=19169582)

------
mstade
At first glance, this seems like a really half baked idea to me. Some
immediate thoughts:

\- Wasn't there a draft spec floating around in the early 00s that tried to
accomplish this, but didn't catch on?

\- Fragments are already used to link to fragments, albeit more author
friendly than user friendly I suppose

\- This won't fly very well with sites that still make use of fragment based
navigation, will it? (Believe it or not, I still see new projects use this
over the history API!)

\- What happens if there's an element in a page with the id or name
`targetText`? This is not mentioned in the very tiny compatibility section[1]
(where some actual data wouldn't hurt, btw)

\- The linked proposal[2] already mentions that more specific fragment
semantics is defined in other media types, so why not follow suit and propose
the HTML spec is amended, instead of making this a user agent feature?

\- Fragments in URLs are already pretty useless in sites that don't load
content until after the dom is ready, i.e. anything that just loads a bunch of
JS and _then_ builds the site in the client – how would this fare any better?

[1]: [https://github.com/bokand/ScrollToTextFragment#web-
compatibi...](https://github.com/bokand/ScrollToTextFragment#web-
compatibility)

[2]: [https://github.com/bokand/ScrollToTextFragment#encoding-
the-...](https://github.com/bokand/ScrollToTextFragment#encoding-the-text-
snippet-in-the-url-fragment)

~~~
leeoniya
> (Believe it or not, I still see new projects use this over the history API!)

want to guess which one doesnt need JS, or server-side handling to work?

~~~
mstade
I think maybe you're misunderstanding what I meant by fragment based
navigation – that's probably my fault. I refer to the shebang style fragments,
that was used to implement deep linking in primarily JS driven sites. This of
course watered down the use of fragments in pages, and nearly made them
useless frankly. Ironically, the history API – which of course as you say
requires JS to work – is what probably saved fragments from being completely
useless, since it meant everyone could return to using paths for deep linking
and _still_ implement their sites as JS blobs if they so chose. Moreover it
opened up for hybrid approaches, where the server can actually serve a pre-
rendered site that's then amended by JS (or not!) since the server would now
see the full path that users were navigating to, as opposed to /my-catch-all-
entry-point. Servers never get to see the fragment, after all.

~~~
leeoniya
the issue is that your server now needs to somehow understand which part of
the path is the "fragment" without any distinguishing characters by which to
parse it out of the url.

if the server now sees deep urls like `/products/patagonia/parkas`, how does
it know which part is the fragment? is it /parkas or /patagonia/parkas? what
if you have urls that are not completely uniform? or have different uniformity
at different prefixes?

the router needs to be more complex. but i agree that the history API has
advantages over shebangs for deep app links.

~~~
mstade
Point isn't so much that the server _needs_ to do anything, you can still just
serve up the same response no matter the path, and have the client render
different results – just as you would with a shebang style navigation in the
past. The difference is that you know have options, which you didn't before
since the server _never_ saw the fragment part of the url, only / or /entry-
point or whatever. So you _can_ have more complex logic server side (really,
this was done in the past long before in-client routing was a thing) but you
don't _have_ to, it can still be deferred to the client to deal with. Using
shebang style navigation you never even really had the option – the history
API enabled this.

~~~
giornogiovanna
Lots of (mostly free) hosting just serves the files you upload, so that
wouldn't work unless you copied the files to be served at every possible
route.

~~~
amichal
“#” Fragments aren’t sent to the server at all. They are ONLY used to get to a
specific anchor (old school) or processed by JavaScript to do something (often
fake navigation by showing and hiding content). This article is adding a 3rd
magic use for them.

~~~
giornogiovanna
Yeah, I know. Parent was saying that the History API doesn't need any server
support, because you can just serve the same file no matter what the subpath,
but my point is that lots of servers don't even have support for that. That's
why the fragment is still more useful than the History API in some cases.

~~~
mstade
Fair point, thanks for adding this perspective! I of course assumed there was
at least a modicum of control over this server side but as you correctly point
out if there is no such control then shebang style navigation is your only
option if indeed you must do client side routing. I once abused custom 404
pages (I think in GH pages, but it may have been some other free host with
similar functionality) in order to achieve this kind of behaviour. It was just
a demo so didn't matter much, but of course this is far from ideal for
anything else.

------
afandian
Something open, standardized, quite similar and already working is Web
annotations. This includes 'robust anchoring' capability which could surely be
used to solve this problem.

[https://www.w3.org/community/openannotation/](https://www.w3.org/community/openannotation/)

Hypothes.is is a well established open implementation.

~~~
will_pseudonym
[https://web.hypothes.is/](https://web.hypothes.is/) is the URL parent was
referring to, but there was a typo.

This looks similar to Genius.com's annotations. I wonder how this will evolve
with multiple providers allowing similar functionality. Ideally you'd be able
to combine annotation networks for a single URI to get all possible
annotations you want on a given page.

Problems with these types of systems are the same as product reviews like on
Amazon. Astroturfing & false information. It'll be interesting to see how that
evolves.

~~~
afandian
Hypothes.is is general purpose but has a focus on scholarship. They have
different namespaces (including global) and work with different communities
(and customers) to provide overlaid environments.

Moderation and curation are perennial issues. Maybe these ovelays will help.
It's not the same, but Reddit has different communities on different
subreddits (with different moderation policies) discussing the same thing.

And re portability, they've made some very encouraging noises about data
portability and exhange. It's baked ito the standard, and their default
content license is, I believe CC something.

Thanks for catching the typo!

------
ChuckMcM
Because that is exactly what we have all been clamoring for. Gee thanks
Google.

Ok, that is more than a bit dismissive and I shouldn't be as cynical as I am
about it but I switched to Firefox for a reason, this crap just keeps
interfering. But oh wait, want to watch Youtube.tv in Firefox, oh so sorry you
can't because it won't do video acceleration. I remember when you had to run
Silverlight to watch Netflix too, that sucked as well.

~~~
r00fus
I use Chrome for a few spare things (like Youtube and full-screen gslides) but
for all else FF or Safari (both with ublock+umatrix) are much better. FF
handles XML rendering way way faster than Chrome - great for my job.

~~~
MHordecki
How do you run umatrix with Safari? I’ve thought it’s not available.

~~~
r00fus
I got that part wrong - sorry to tease. No uMatrix in my Safari. Just content
blocker + ublock-origin.

------
ipsum2
I can't find an RFC about this, but it looks like something similar has been
proposed in the past, with a slightly different API.

> In URIs for MIME text/plain documents RFC 5147 specifies a fragment
> identifier for the character and line positions and ranges within the
> document using the keywords "char" and "line". Some popular browsers do not
> yet support RFC 5147.[5] The following example identifies lines 11 through
> 20 of a text document:
> [http://example.com/document.txt#line=10,20](http://example.com/document.txt#line=10,20)

[https://en.wikipedia.org/wiki/Fragment_identifier](https://en.wikipedia.org/wiki/Fragment_identifier)

~~~
larkeith
I must say I prefer the RFC version - while still vulnerable to rotting from
text changes, at least it should still link to the same general vicinity.

~~~
mediumdeviation
HTML documents don't generally have the concept of lines since text reflow
based on the way user agent (browser) is rendering the document. That's why
the RFC only talks about text/plain MIME type - browsers render those with all
line breaks intact. You can maybe use a CSS selectors, but that adds a
tremendous amount of complexity and is not easy for non-web developers to read
anymore.

~~~
larkeith
Oops, good point. I suppose you could do by newline/paragraph plus character
instead, but that would be even more vulnerable to text changes.

------
abalone
Very significant limitation: it only links to the first instance of the target
text.

What is the expected behavior if you highlight a second instance of some
target text and try to create a link to it? It’s bad that the spec doesn’t
discuss it. I can see this happening with short selections, like linking to a
single word.

Seems like this could use more thought.

~~~
jchw
I think this is being over thought a bit. Even in it's most primitive form, it
could still be quite useful in practice.

It's pretty easy to construct cases where it fails, but _all_ such systems
will fail either due to changes in content or changes in structure, and many
will fail due to ambiguity as well. It's only really useful to compare how
this might fare against other approaches. An example would be producing an
XPath expression. Which may be more robust to ambiguity but weaker to
structural changes.

This system will fail if the content is different enough that the target text
is gone, which I believe is very reasonable. And while you could construct
ambiguous text that couldn't be disambiguated by picking a larger string, in
practice the value added with the complexity of trying to solve that problem
is probably not very good. For the purpose of linking to sentences and
paragraphs, this system seems sufficient and probably even better than many
alternatives. I don't think many articles have a lot of repeating sentences.

Other use cases than linking to actual text would probably have their issues.
Like, trying to link to a cell of a table would be quite problematic. That
case may be better handled with something like an XPath expression, but in any
case it's a fairly different use case imo.

All in all, my initial opinion is that this design is useful and easy to
understand. It gives you the equivalent of Ctrl+F which is not bad.

(Disclosure: I work at Google, but this is the first I've heard of this and I
don't work on Chrome.)

~~~
beatgammit
Why not just use fragments? It's pretty easy to place a unique fragment at all
places you care to link, except perhaps in the very nice case of
reimplementing Ctrl+F, which would need JS anyway, so why not just expose an
API call, like window.find[1]?

I really don't understand what this brings to the table, besides making people
upset.

[1] [https://developer.mozilla.org/en-
US/docs/Web/API/Window/find](https://developer.mozilla.org/en-
US/docs/Web/API/Window/find)

~~~
jchw
Simple, it doesn't depend on requiring the content to have lots of
identifiers. While you may convince some web developers to just add more
identifiers, you can't convince everyone. And for largely unstructured plain
text like mailing list archives, there's not really a logical way to do that
anyways.

Re: making people upset. I mean, nearly anything will upset people. One way a
search engine could incentivize people to add more usable fragment identifiers
is by ranking pages with them higher, but I am certain many wouldn't be
thrilled by that.

If this is implemented I don't think it will actually raise serious
compatibility issues, and it's not a huge deal to remove it later, it should
degrade softly.

------
_bxg1
It seems like more and more, Google is leveraging their near-monopoly on web
browsing to just skip the proposal process and do whatever they want without
discussion.

~~~
dannyr
I agree with you on Google's monopoly but imagine if every browser has to go
through proposal process to release any feature? Everything will just
stagnate.

Browsers copy features from each other. If this is a useful feature, it would
make its way to other browsers pretty soon.

~~~
adrianN
Stagnation is not always bad. For one, it helps keep complexity down. We're at
a point where building a browser is impossible unless you have literally
millions and millions of dollars to invest. That is not good.

~~~
SquareWheel
If building from scratch maybe, but when was the last time a browser was built
from scratch? Even Chromium was forked from WebKit.

~~~
adrianN
That's my point. The web is so complex that browser engines are becoming a
monoculture. Even if you forked Chromium now, you'd need hundreds of engineers
just to keep up with all the new things that are constantly added.

~~~
izacus
And yet the fact that the major engine implementation is opensource still
allows each vendor to innovate by adding new useful features to the users.

We're really far from IE6 era of complete stagnation.

~~~
pcwalton
Not really, as far as the core browser engine tech goes. In practice it's too
difficult to maintain a Chromium fork that diverges in any significant way
other than the front end. Opera and Edge (per announcement) use vanilla
upstream Blink.

------
peter303
Almost caught up to the capabilities of Ted Nelsons Xanadu Hypertext System
from the mid 20th century.

~~~
kumarharsh
I was just seeing a documentary about him (the Internet actually) by Werner
Herzog. It was the first time I had heard about Xanadu or Ted Nelson. His
ideas were quite radical from what I know as the Web. And I got to thinking
how the web might have been had Xanadu become mainstream.

But then I opened the Wikipedia page on Project Xanadu, it's second paragraph
is:

> Wired magazine published an article called "The Curse of Xanadu", calling
> Project Xanadu "the longest-running vaporware story in the history of the
> computer industry".[2] The first attempt at implementation began in 1960,
> but it was not until 1998 that an incomplete implementation was released. A
> version described as "a working deliverable", OpenXanadu, was made available
> in 2014.

So... I don't know what to make of it.

~~~
kabes
It's basically as if he proposed a teleportation device, but couldn't deliver
any of it. And when Tim berners Lee build an airplane which everybody started
using he starts complaining on how much better his idea was. In recent years
he's only been doing that last thing.

------
kumarharsh
Seems very cool!

But the functionality feels like it'd be prone to breakage as new text is
added to the document (possible in Wikipedia articles for example). But it'd
be super-helpful for search engines as they will have a relatively recent copy
of the text, and can auto-generate the links on the backend before showing the
search results to the user.

~~~
colordrops
I'd assume a hash of the content would be included with the link, and if the
hash changes, then it would make a best-effort guess at the right location,
with a different color highlight indicating that it's a guess. At least that's
how I would do it.

~~~
bokan
What would you hash though? Content on a page changes frequently and
dynamically so the hash would mismatch very frequently.

------
fouc
Is this going to lead to an api of #<keywords> for different scrolling to
behavior?

Also, what happens if the page already has an anchor text that happens to be
the exact match? i.e. #targetText=My%20Heading is already an existing anchor

~~~
hboon
Then the = should be encoded as %23 in the URL and should not be interpreted
as #targetText=<encoded target text>

------
eecc
Let me guess, it has nothing to do with
[https://www.w3.org/community/openannotation/](https://www.w3.org/community/openannotation/)

~~~
Yizahi
"Look at you, standards committee - a pathetic creature of humans and ideals,
panting and sweating as you chase after my unrestrained "innovations". How can
you challenge a perfect, immortal GOOGLE!" (c) Shodan, probably

------
pjtr
Similar Javascript feature existed for a long time:

Link to first occurrence of "pseudo" on page:
[https://trac.edgewall.org/wiki/TracLinks#/pseudo](https://trac.edgewall.org/wiki/TracLinks#/pseudo)

Link to last occurrence of "highlight" on page:
[https://trac.edgewall.org/browser/trunk/trac/htdocs/js/searc...](https://trac.edgewall.org/browser/trunk/trac/htdocs/js/search.js#?highlight)

------
chaz6
How is this supposed to work when most web pages these days are a mash of
dynamically generated javascript?

~~~
emersion
Same as regular URL hash I guess? (Browsers tend to wait a little if they
don't find the target)

------
fooyc
Can this be used to gain some informations about the content of a webpage,
with a timing attack ?

Searching a phrase on a webpage will be faster when the phrase exists, on
average. If this timing is observable, this could be exploited to guess the
content of a web page.

Someone did this already with selector-based anchors:
[https://blog.sheddow.xyz/css-timing-attack/](https://blog.sheddow.xyz/css-
timing-attack/)

~~~
bokan
Feature author here.

The CSS timing attack actually influenced the design process heavily. The
original design was to use a stripped down CSS selector but we found this too
large of an attack surface.

There's definitely still concerns around making sure a 3rd party can't
exfiltrate information from the page using this but we think we've found a set
of restrictions that should prevent this:
[https://github.com/bokand/ScrollToTextFragment#security](https://github.com/bokand/ScrollToTextFragment#security)

------
dak1
Using the hash for navigation is still quite common, because usage of history
pushState requires server support to correctly work on reload.

I’d also argue that SPAs using it for navigation are not abusing it. The
purpose is to allow linking to different sections in a document. Navigation is
effectively an advanced form of the same concept. It’s just that as you
navigate, the DOM happens to mutate to bring the content you linked to into
view, instead of just scrolling down to it.

Hash fragments are for page authors to define, not the browser. While this
sounds like a useful feature, it’s implementation is simply wrong.

What they really want to do is extend the RFC for URLs to add an additional
component. There are already unsafe characters that could be used for this
purpose that would be nonbreaking.

For example, add a | at the end of the hash fragment, and anything after that
can be for the browser to communicate page state independent of the page
author’s intent.

The current proposal, however, should be firmly rejected.

------
josteink
So Chrome users will unknowingly be offered to create links which won’t work
in other browsers?

How come I’m not surprised?

These links should if nothing else be prefixed chrome:// to be explicit about
it not being real web-links.

~~~
pbhjpbhj
Does that help, surely that just means other browsers have to support
chrome:// if they decide to adopt that feature?

------
acd
Track what you and your friends like, build a graph mine that data and earn
more ad revenue.

------
dmortin
I'd like this for PDFs. Often I want to share a PDF opened at a specific text.
You can create a pdf url which jumps to a certain page. You can even link to a
search for a certain word (single word).

But I can't link to a search phrase in a PDF. For some reason, they
implemented searching for single words, but not phrases.

~~~
saagarjha
Searching for text in PDFs is a not easy to do in general.

------
or113
I actually wrote a really similar extension a year ago, please give me
feedback!

[https://chrome.google.com/webstore/detail/target-
search/nohm...](https://chrome.google.com/webstore/detail/target-
search/nohmjponpgbnhjokbmagdbnjpnmdaigb)

------
DarkWiiPlayer
Hey, let's break standards in a dumb way, what could _possibly_ go wrong?

------
aesthetics1
Interesting. I think this is useful if implemented correctly.

I had an idea similar to this a few years ago. Basically, you would be able to
bookmark your place on the page and come back to it later or send the link to
someone else. I didn't think that using a word or phrase was useful because it
could show up multiple times on the page. Instead, I used the scroll distance.
Here's a crude demo:

[http://jboyer87.github.io/page-progress/](http://jboyer87.github.io/page-
progress/)

Of course, this isn't device-independent. I never went much further with it.

------
phillipseamore
I remember how many websites (15+ years ago) used to offer something similar
to this. JS would pick out the query used on a search engine (and sent with
the referrer) to scroll to and highlight matches to the query.

------
Abishek_Muthian
This is indeed very useful feature to share specific content. I built larynx
'A tool to share content along with voice' with similar intention. In larynx a
user can share screenshot of the particular snippet along with voice.

I wanted to build a similar future in the feature where clicking the link
would take the user directly to the snippet, of-course it would work only
inside larynx apps; but with chromium penetration Google can implement this
feature seamlessly.

[1]: [https://larynx.io](https://larynx.io)

------
nscalf
I'm very excited about this. I've always thought this should be a fundamental
part of linking the web. Along with linking to times in videos, audio, etc. I
think youtube allowing you to jump to a certain time via the url is a great
example. I've wanted to share podcasts down to a specific point in a
conversation many times, and if it wasn't a video, I didn't know how to do it.
It just feels like a fundamental way to share information.

------
sasasassy
This breaks so much stuff. So many websites use #something for a myriad of
purposes. And it's their discretion, their website. I've never even seen
#arg=val used in URIs ever, so nothing would be expecting that. Or
#arg1=val1&arg2=val2.

This feels just like when I discovered that one day Chrome just decided to use
the canonical address of a page instead of the actual address, when sharing
it, telling no one. These people are a plague on this world.

------
givinguflac
Glad to see google wasting no time on their new browser monopoly to screw up
everyone else’s experience and push their own vision for the web. /s

------
aaaaaaaaaaab

        #targetText=whatever
    

Ew, this is so hacky and bolted-on.

But I guess this is the price we pay for letting the WHATWG go on with their
coup against W3C.

------
aboutruby
Great feature and a pretty straightforward polyfill, could even be implemented
before Chrome releases it (the context menu to get the link being the hard
part, but a select text + tooltip with "Copy link to this text" would work, or
I'm pretty sure good designers will find great UIs for it, might even
normalizes as a new pattern)

------
jeena
This really reminds me of
[https://indieweb.org/fragmention](https://indieweb.org/fragmention)

What I don't get is how it will be handled if you have more than one
occurrence of the phrase on that page.

------
donohoe
The usage isn't as _pretty_ as Chromes but usage allows for changes in
original text to not break the link:

[https://github.com/NYTimes/Emphasis](https://github.com/NYTimes/Emphasis)

------
ajkjk
I love this, or at least the general idea that it represents, though the
specific implementation might be a little odd. (I'd rather the link to be some
sort of 'coordinate' \-- like a CSS selector, but for text?)

~~~
giornogiovanna
Something like
[https://news.ycombinator.com/item?id=19169582](https://news.ycombinator.com/item?id=19169582)
?

------
iamapipebomb
firefox has an extension that does similar [https://addons.mozilla.org/en-
US/firefox/addon/pinpointer/](https://addons.mozilla.org/en-
US/firefox/addon/pinpointer/) discussed here
[https://news.ycombinator.com/item?id=17556805](https://news.ycombinator.com/item?id=17556805)

------
rajangdavis
In my mind's eye, I can see someone chaining multiple events to trigger
malicious behavior with this.

-Would the scrolling occur AFTER page load?

-What if the text that is passed in is removed/never existed?

-What if the text exists in multiple places? I guess it immediately goes to the first instance, but if you are trying to link to the second, third, etc., this API wouldn't work...

-What if the text screws up a URL query parameter?

-How will this impact SEO?

-Would this still work if the parent element of a text node is set to "display:none"?

I just hope it doesn't become a thing with sites relying on this
functionality.

------
moogly
During my, I dunno, 25 years on the internet, the number of times I've wanted
to do this is 0. Not sure about the value proposition here.

------
Alexander473
I bet this has been possible to accomplish with a custom browser extension.
And also, services like Evernote or Genius might help.

------
foobarbecue
So... like xpath?

~~~
tirpen
Yes, but worse. There is not a single day when I'm not annoyed that xhtml was
abandoned.

------
brokenmachine
It would be nice if google would link to the part of the webpage where your
search text appears.

Maybe this is a step towards that goal.

------
2038AD
Another feature inching closer to Xanadu. Excited for this!

------
vietvu
Like Medium?

------
ped4enko
good news for UX

------
ped4enko
wow

------
sascha_sl
Everyone in this thread needs to put their money where their mouth is and go
back to Firefox if they're currently using Chrome.

~~~
Slartie
Did exactly this, a few weeks ago. Was heavy Chrome user, now fully on Firefox
(and Safari on mobile). I am so satisfied with this decision, and the
transition was much easier than expected.

~~~
fareesh
I would do it instantly if the devtools were half as convenient as Chrome.
Unfortunately they are super clunky

~~~
martin_a
What are you missing? I was feared of this too, but they seem to be just fine.

~~~
chillydawg
Can't inspect websocket frames. It's ridiculous.

~~~
martin_a
I'm out of that, but maybe somebody else in here got an idea how to fix your
problem with that.

~~~
chillydawg
My solution is to use chrome when faced with that particular limitation.
There's a bug open on the mozilla tracker and it's been there for a while but
no one seems to care.

------
gcb0
Real use case for this is so Google can poke into context for links shared via
services they have no ownership.

They got used to know exactly what people share and, much more importantly,
what people click on email, thanks to gmail rewriting all links to a google
track url (while misleading the user by a fake status text on mouse over).
When they sum the info of 1. who send it, 2. who clicked on it, 3. what was
the email context, they can further classify the page content. (for ads,
search ranking, whatever they do today)

But they can't do that on whatsapp, facebook, etc. With this "feature", now
they have at least a modicum of context when the page impression show up on
their Google Analytics trackers. Did you visit that wikipedia page because of
recent news events, or doing homework?

Or, we could just go with occam's razor and believe that a bunch of bored
engineers at google decided to simply add a feature completely disconnected
from any of their business plans, and spent a few months tweaking a git repo
with nothing but a README file... while the actual code review has follow up
questions that were left open and merged anyway: [https://chromium-
review.googlesource.com/c/chromium/src/+/14...](https://chromium-
review.googlesource.com/c/chromium/src/+/1434215/17/third_party/blink/renderer/core/page/scrolling/text_fragment_finder.cc#57)
¯\\_(ツ)_/¯

~~~
nerdponx
It's a shame because it is actually a good idea, but now Google has first-
mover advantage, so any other implementations will just be a clone of what
Google already did.

~~~
Izkata
[http://archive.is/](http://archive.is/) got there first, sort of. If you
archive a page then highlight some text, the URL changes to a direct shareable
link to that text.

Bonus: being its own site, and implemented in javascript, it's already cross-
browser.

------
fxfan
I am having trouble deciding if Google has finally beaten Microsoft on the 'we
can do what we want to' front, specially given that Microsoft is running
backwards in that race of-late?

