37 ms·

Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

361 points by kumaranvpl 8y ago

fouc 8y ago
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 8y ago
  Then the = should be encoded as %23 in the URL and should not be interpreted as #targetText=<encoded target text>
ipsum2 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      Oops, good point. I suppose you could do by newline/paragraph plus character instead, but that would be even more vulnerable to text changes.
- csarven 8y ago
  Right on. Different fragment selectors can be used depending on the media type of a representation: https://www.w3.org/TR/selectors-states/#selector https://www.w3.org/TR/selectors-states/#selector Expanded here: https://news.ycombinator.com/item?id=19169582 https://news.ycombinator.com/item?id=19169582
peter303 8y ago
Almost caught up to the capabilities of Ted Nelsons Xanadu Hypertext System from the mid 20th century.
- elvinyung 8y ago
  1980s is not "mid 20th century".
  - kumarharsh 8y ago
    It was proposed in the 1960s as per Wikipedia.
- kumarharsh 8y ago
  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 8y ago
    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.
j16sdiz 8y ago
I hope the internet God would kill one chrome engineer for each existing page they have broke.
kumarharsh 8y ago
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.
- taeric 8y ago
  I'm on the one hand skeptical of the idea being useful, and on the other acknowledging that emacs' ability to open a file on a line and word is quite useful. (Basically, the results of grep can be directly fed to emacs to jump to the result.)(I'm sure this is not limited to emacs.) You are right that the link is somewhat time limited. However, tools like emacs and ctags show this can be somewhat worked with. Instead of the very specific links that grep creates, generate one that has a location, but also a small pattern that indicates it. To that end, you could generate a link to the word "breakage" with a selector saying where it is expected. And the browser can then just fudge around that selector to find that word. Or highlight where it was expected.
- colordrops 8y ago
  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 8y ago
    What would you hash though? Content on a page changes frequently and dynamically so the hash would mismatch very frequently.
- extra88 8y ago
  As described in the Here is How This will Work section, the implementation is humble. It either scrolls the page to the first instance to the string in the fragment or it scrolls and highlights text included and between two comma-separated strings (commas in the strings themselves would need to be url encoded). If you wanted to scroll to the nth instance of a string, you've have to use the latter format and include more text, making it unique or at least the first instance. Yes, it would fail if the target text no longer exists in the page but link rot is already commonplace. It would be important for it to ignore DOM elements, it can't fail because the target text crosses two paragraphs or a span.
abalone 8y ago
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.
- pasiaj 8y ago
  Doesn’t the spec specify, that the link points to the first instance of the selected text? Does that not accurately define what happens when you try to link to a latter instance: It links to the first one.
  - Buge 8y ago
    This isn't a question about where the browser will scroll. This is a question about what will the browser do if the user tries to create a link to something that can't be scrolled to.
  - larkeith 8y ago
    That's not great from a UX point of view - for most users, their experience with the feature will be trying to use it, selecting a phrase, and having it silently link to an entirely different area.
- kumarharsh 8y ago
  Although you are right, it's already how browsers work in relation to IDs - only the first element with that ID is selected. (Yes, IDs are supposed to be unique, but it's not like HTML "breaks" if you don't follow this rule). Plus, you can always select more text.
- dmortin 8y ago
  They could add and index too, but linking to a search phrase is already prone to breakage if the text changes, so there's not much point in complicating it. Usually the same phrase is not repeated in the text if you select more than 1-2 words.
aboutruby 8y ago
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)
_bxg1 8y ago
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.
- est 8y ago
  in this case it looked OK > Though existing HTML support for id and name attributes specifies the target element directly in the fragment, most other mime types make use of this x=y pattern in the fragment, such as Media Fragments (e.g. #track=audio&t=10,20), PDF (e.g. #page=12) or CSV (e.g. #row=4). fragments is already there but most pages do not have a clickable ID attribute. If Chrome could automatically provide one I think it's more convenient than F12 a devtool for links.
  - pjmlp 8y ago
    IE 5 was also welcomed with joy when it arrived.
  - peteretep 8y ago
    > in this case it looked OK That’s not really the point
    - gammateam 8y ago
      I’m fine skiing down this slippery slope
  - detaro 8y ago
    Although there already was a proposed standard by a W3C group for doing this, although it is a lot more complicated (with a bunch of variations, but even implementing one of those would be nice): https://www.w3.org/TR/selectors-states/#json-examples-converted-to-fragment-identifiers https://www.w3.org/TR/selectors-states/#json-examples-conver...
- jonathankoren 8y ago
  It’s almost as if Google is the new Microsoft!
dmortin 8y ago
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 8y ago
  Searching for text in PDFs is a not easy to do in general.
ajkjk 8y ago
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 8y ago
  Something like https://news.ycombinator.com/item?id=19169582 https://news.ycombinator.com/item?id=19169582 ?
throwaway415415 8y ago
Inb4 security people start complaining about the privacy issues.
capitalone 8y ago
This is a great news.
foobarbecue 8y ago
So... like xpath?
- tirpen 8y ago
  Yes, but worse. There is not a single day when I'm not annoyed that xhtml was abandoned.
eecc 8y ago
Let me guess, it has nothing to do with https://www.w3.org/community/openannotation/ https://www.w3.org/community/openannotation/
- Yizahi 8y ago
  "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
ChuckMcM 8y ago
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 8y ago
  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 8y ago
    How do you run umatrix with Safari? I’ve thought it’s not available.
    - r00fus 8y ago
      I got that part wrong - sorry to tease. No uMatrix in my Safari. Just content blocker + ublock-origin.
- Yizahi 8y ago
  I recently started to run into new IE6 stuff - bank plugin for certificates that was made only for Chrome, then on mobile some ecommerce site which simply didn't work in mobile FF (real one, on android), stuff like that. I suspect there will be way more of this monopolistic crap now that FF has fallen below 10% and Edge died.
- pwg 8y ago
  For youtube watching, youtube-dl works nicely for much of youtube, and after you download the video, presumably your local player can make use of all your hardware acceleration that might be available. http://rg3.github.io/youtube-dl/about.html http://rg3.github.io/youtube-dl/about.html
pjtr 8y ago
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/search.js#?highlight https://trac.edgewall.org/browser/trunk/trac/htdocs/js/searc...
mstade 8y ago
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-compatibility https://github.com/bokand/ScrollToTextFragment#web-compatibi... [2]: https://github.com/bokand/ScrollToTextFragment#encoding-the-text-snippet-in-the-url-fragment https://github.com/bokand/ScrollToTextFragment#encoding-the-...
- leeoniya 8y ago
  > (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 8y ago
    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.
gcb0 8y ago
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/+/1434215/17/third_party/blink/renderer/core/page/scrolling/text_fragment_finder.cc#57 https://chromium-review.googlesource.com/c/chromium/src/+/14... ¯\_(ツ)_/¯
- nerdponx 8y ago
  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.
  - dmurray 8y ago
    Isn't that...better than every browser having an incompatible implementation of it, so Firefox users could only share links with Firefox users, etc? I get the argument that it's better for these things to be done by consensus among the browser makers. Is it in scope for WHATWG?
  - Izkata 8y ago
    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.
myfonj 8y ago
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 8y ago
  Cool, it's like it's exposing Ctrl+F.
chaz6 8y ago
How is this supposed to work when most web pages these days are a mash of dynamically generated javascript?
- emersion 8y ago
  Same as regular URL hash I guess? (Browsers tend to wait a little if they don't find the target)
phillipseamore 8y ago
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.
vietvu 8y ago
Like Medium?
acd 8y ago
Track what you and your friends like, build a graph mine that data and earn more ad revenue.
deleted 8y ago
[deleted]
afandian 8y ago
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 8y ago
  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 8y ago
    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!
  - gioele 8y ago
    > 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 » At least one member of the Hypothesis team came from Genius (formerly Rap Genius) which is the largest annotation service on the web.« https://news.ycombinator.com/item?id=13739965 https://news.ycombinator.com/item?id=13739965
Alexander473 8y ago
I bet this has been possible to accomplish with a custom browser extension. And also, services like Evernote or Genius might help.
josteink 8y ago
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 8y ago
  Does that help, surely that just means other browsers have to support chrome:// if they decide to adopt that feature?
xg15 8y ago
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...
- sascha_sl 8y ago
  Hmm, who provided the first popular JS framework that used fragments for navigation again? I think it was called "Angular".
  - chrismorgan 8y ago
    Gmail was probably the first very-widely-used app that used the fragment for navigation, and Google drove the whole #! thing. That technique is now considered obsolete, with the History API (history.pushState and all that lot) having supplanted it. IE9 is the most popular browser currently in use that doesn’t support it; there are still definitely some systems out there that will use the History API if it’s available, or fall back to using the hash if it’s not, but I find that using the hash for navigation in deployed apps is surprisingly dead, given that it’s shy of six and a half years since IE10 came out, and Firefox and Chrome only had a year and two’s lead (and Chrome’s implementation especially was unreliable for quite some time). Using the hash for navigation is still very common in development workflows. But that can be ignored for a feature like this.
2038AD 8y ago
Another feature inching closer to Xanadu. Excited for this!
sascha_sl 8y ago
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 8y ago
  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 8y ago
    I would do it instantly if the devtools were half as convenient as Chrome. Unfortunately they are super clunky
    - martin_a 8y ago
      What are you missing? I was feared of this too, but they seem to be just fine.
      - chillydawg 8y ago
        Can't inspect websocket frames. It's ridiculous.
        martin_a 8y ago
        I'm out of that, but maybe somebody else in here got an idea how to fix your problem with that.
        chillydawg 8y ago
        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.
aaaaaaaaaaab 8y ago
#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.
csarven 8y ago
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=TextQuoteSelector,prefix=ed%2C%20browser-based%20authoring%20and%20,exact=annotation,suffix=%20platform%20with%20built-in%20support%20) http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto... A screenshot/how-to: https://twitter.com/csarven/status/981924087843950595 https://twitter.com/csarven/status/981924087843950595
- fock 8y ago
  Typical GOOG move. Add some code, break the web outside the Google way. Why can't those guys write an RFC "Content sublocator-protocol for diverse media"... Well, I started writing this and read your answer. This is not a problem specific to html/the web, for example I regularly encounter this when referencing things in pdfs. Will definitely have a look at this!
- ru999gol 8y ago
  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
  - raimue 8y ago
    The W3C design seems to be extensible for future use cases with a consistent syntax while keeping everything under one keyword. Something like this could also be applied to other types of documents, not only to text. Let's say to quickly draw a highlight on an image or specify a page in a PDF document. While "#targetText=" is simple, it is not a generic solution.
DarkWiiPlayer 8y ago
Hey, let's break standards in a dumb way, what could possibly go wrong?
fxfan 8y ago
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?
ped4enko 8y ago
wow
rajangdavis 8y ago
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.
fooyc 8y ago
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 8y ago
  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
amitjam 8y ago
http://www.alerttips.com/ http://www.alerttips.com/
Abishek_Muthian 8y ago
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
donohoe 8y ago
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
deleted 8y ago
[deleted]
severak_cz 8y ago
Despite it's flaws I found this thing really useful. Much more useful (for user) than utm_source & fbclid which pollutes todays URLs. However, i think that the functionality should be in browser extension not browser itself.
ped4enko 8y ago
good news for UX
gioele 8y ago
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 8y ago
  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
- ben174 8y ago
  I suppose it could be argued that the DOM might change on a page, but the text content is less likely to. We want deep links to the text content, not the DOM element.
dak1 8y ago
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.
givinguflac 8y ago
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
iamapipebomb 8y ago
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
or113 8y ago
I actually wrote a really similar extension a year ago, please give me feedback! https://chrome.google.com/webstore/detail/target-search/nohmjponpgbnhjokbmagdbnjpnmdaigb https://chrome.google.com/webstore/detail/target-search/nohm...
jeena 8y ago
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.
nscalf 8y ago
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.
aesthetics1 8y ago
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.
moogly 8y ago
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.
Proven 8y ago
Very helpful... to Google's monetization of those who share links that way. I think I'll pass.
sasasassy 8y ago
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.
brokenmachine 8y ago
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.

361 points by kumaranvpl 8y ago

fouc 8y ago

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 8y ago
Then the = should be encoded as %23 in the URL and should not be interpreted as #targetText=<encoded target text>

ipsum2 8y ago

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 8y ago
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 8y ago
  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 8y ago
    Oops, good point. I suppose you could do by newline/paragraph plus character instead, but that would be even more vulnerable to text changes.
csarven 8y ago
Right on. Different fragment selectors can be used depending on the media type of a representation: https://www.w3.org/TR/selectors-states/#selector https://www.w3.org/TR/selectors-states/#selector Expanded here: https://news.ycombinator.com/item?id=19169582 https://news.ycombinator.com/item?id=19169582

peter303 8y ago

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

elvinyung 8y ago
1980s is not "mid 20th century".
- kumarharsh 8y ago
  It was proposed in the 1960s as per Wikipedia.
kumarharsh 8y ago
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 8y ago
  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.

j16sdiz 8y ago

I hope the internet God would kill one chrome engineer for each existing page they have broke.

kumarharsh 8y ago

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.

taeric 8y ago
I'm on the one hand skeptical of the idea being useful, and on the other acknowledging that emacs' ability to open a file on a line and word is quite useful. (Basically, the results of grep can be directly fed to emacs to jump to the result.)(I'm sure this is not limited to emacs.) You are right that the link is somewhat time limited. However, tools like emacs and ctags show this can be somewhat worked with. Instead of the very specific links that grep creates, generate one that has a location, but also a small pattern that indicates it. To that end, you could generate a link to the word "breakage" with a selector saying where it is expected. And the browser can then just fudge around that selector to find that word. Or highlight where it was expected.
colordrops 8y ago
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 8y ago
  What would you hash though? Content on a page changes frequently and dynamically so the hash would mismatch very frequently.
extra88 8y ago
As described in the Here is How This will Work section, the implementation is humble. It either scrolls the page to the first instance to the string in the fragment or it scrolls and highlights text included and between two comma-separated strings (commas in the strings themselves would need to be url encoded). If you wanted to scroll to the nth instance of a string, you've have to use the latter format and include more text, making it unique or at least the first instance. Yes, it would fail if the target text no longer exists in the page but link rot is already commonplace. It would be important for it to ignore DOM elements, it can't fail because the target text crosses two paragraphs or a span.

abalone 8y ago

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.

pasiaj 8y ago
Doesn’t the spec specify, that the link points to the first instance of the selected text? Does that not accurately define what happens when you try to link to a latter instance: It links to the first one.
- Buge 8y ago
  This isn't a question about where the browser will scroll. This is a question about what will the browser do if the user tries to create a link to something that can't be scrolled to.
- larkeith 8y ago
  That's not great from a UX point of view - for most users, their experience with the feature will be trying to use it, selecting a phrase, and having it silently link to an entirely different area.
kumarharsh 8y ago
Although you are right, it's already how browsers work in relation to IDs - only the first element with that ID is selected. (Yes, IDs are supposed to be unique, but it's not like HTML "breaks" if you don't follow this rule). Plus, you can always select more text.
dmortin 8y ago
They could add and index too, but linking to a search phrase is already prone to breakage if the text changes, so there's not much point in complicating it. Usually the same phrase is not repeated in the text if you select more than 1-2 words.

aboutruby 8y ago

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)

_bxg1 8y ago

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.

est 8y ago
in this case it looked OK > Though existing HTML support for id and name attributes specifies the target element directly in the fragment, most other mime types make use of this x=y pattern in the fragment, such as Media Fragments (e.g. #track=audio&t=10,20), PDF (e.g. #page=12) or CSV (e.g. #row=4). fragments is already there but most pages do not have a clickable ID attribute. If Chrome could automatically provide one I think it's more convenient than F12 a devtool for links.
- pjmlp 8y ago
  IE 5 was also welcomed with joy when it arrived.
- peteretep 8y ago
  > in this case it looked OK That’s not really the point
  - gammateam 8y ago
    I’m fine skiing down this slippery slope
- detaro 8y ago
  Although there already was a proposed standard by a W3C group for doing this, although it is a lot more complicated (with a bunch of variations, but even implementing one of those would be nice): https://www.w3.org/TR/selectors-states/#json-examples-converted-to-fragment-identifiers https://www.w3.org/TR/selectors-states/#json-examples-conver...
jonathankoren 8y ago
It’s almost as if Google is the new Microsoft!

dmortin 8y ago

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 8y ago
Searching for text in PDFs is a not easy to do in general.

ajkjk 8y ago

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 8y ago
Something like https://news.ycombinator.com/item?id=19169582 https://news.ycombinator.com/item?id=19169582 ?

throwaway415415 8y ago

Inb4 security people start complaining about the privacy issues.

capitalone 8y ago

This is a great news.

foobarbecue 8y ago

So... like xpath?

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

eecc 8y ago

Let me guess, it has nothing to do with https://www.w3.org/community/openannotation/ https://www.w3.org/community/openannotation/

Yizahi 8y ago
"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

ChuckMcM 8y ago

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 8y ago
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 8y ago
  How do you run umatrix with Safari? I’ve thought it’s not available.
  - r00fus 8y ago
    I got that part wrong - sorry to tease. No uMatrix in my Safari. Just content blocker + ublock-origin.
Yizahi 8y ago
I recently started to run into new IE6 stuff - bank plugin for certificates that was made only for Chrome, then on mobile some ecommerce site which simply didn't work in mobile FF (real one, on android), stuff like that. I suspect there will be way more of this monopolistic crap now that FF has fallen below 10% and Edge died.
pwg 8y ago
For youtube watching, youtube-dl works nicely for much of youtube, and after you download the video, presumably your local player can make use of all your hardware acceleration that might be available. http://rg3.github.io/youtube-dl/about.html http://rg3.github.io/youtube-dl/about.html

pjtr 8y ago

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/search.js#?highlight https://trac.edgewall.org/browser/trunk/trac/htdocs/js/searc...

mstade 8y ago

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-compatibility https://github.com/bokand/ScrollToTextFragment#web-compatibi... [2]: https://github.com/bokand/ScrollToTextFragment#encoding-the-text-snippet-in-the-url-fragment https://github.com/bokand/ScrollToTextFragment#encoding-the-...

leeoniya 8y ago
> (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 8y ago
  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.

gcb0 8y ago

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/+/1434215/17/third_party/blink/renderer/core/page/scrolling/text_fragment_finder.cc#57 https://chromium-review.googlesource.com/c/chromium/src/+/14... ¯\_(ツ)_/¯

nerdponx 8y ago
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.
- dmurray 8y ago
  Isn't that...better than every browser having an incompatible implementation of it, so Firefox users could only share links with Firefox users, etc? I get the argument that it's better for these things to be done by consensus among the browser makers. Is it in scope for WHATWG?
- Izkata 8y ago
  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.

myfonj 8y ago

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 8y ago
Cool, it's like it's exposing Ctrl+F.

chaz6 8y ago

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

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

phillipseamore 8y ago

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.

vietvu 8y ago

Like Medium?

acd 8y ago

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

deleted 8y ago

[deleted]

afandian 8y ago

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 8y ago
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 8y ago
  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!
- gioele 8y ago
  > 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 » At least one member of the Hypothesis team came from Genius (formerly Rap Genius) which is the largest annotation service on the web.« https://news.ycombinator.com/item?id=13739965 https://news.ycombinator.com/item?id=13739965

Alexander473 8y ago

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

josteink 8y ago

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 8y ago
Does that help, surely that just means other browsers have to support chrome:// if they decide to adopt that feature?

xg15 8y ago

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...

sascha_sl 8y ago
Hmm, who provided the first popular JS framework that used fragments for navigation again? I think it was called "Angular".
- chrismorgan 8y ago
  Gmail was probably the first very-widely-used app that used the fragment for navigation, and Google drove the whole #! thing. That technique is now considered obsolete, with the History API (history.pushState and all that lot) having supplanted it. IE9 is the most popular browser currently in use that doesn’t support it; there are still definitely some systems out there that will use the History API if it’s available, or fall back to using the hash if it’s not, but I find that using the hash for navigation in deployed apps is surprisingly dead, given that it’s shy of six and a half years since IE10 came out, and Firefox and Chrome only had a year and two’s lead (and Chrome’s implementation especially was unreliable for quite some time). Using the hash for navigation is still very common in development workflows. But that can be ignored for a feature like this.

2038AD 8y ago

Another feature inching closer to Xanadu. Excited for this!

sascha_sl 8y ago

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 8y ago
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 8y ago
  I would do it instantly if the devtools were half as convenient as Chrome. Unfortunately they are super clunky
  - martin_a 8y ago
    What are you missing? I was feared of this too, but they seem to be just fine.
    - chillydawg 8y ago
      Can't inspect websocket frames. It's ridiculous.
      - martin_a 8y ago
        I'm out of that, but maybe somebody else in here got an idea how to fix your problem with that.
        chillydawg 8y ago
        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.

aaaaaaaaaaab 8y ago

#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.

csarven 8y ago

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=TextQuoteSelector,prefix=ed%2C%20browser-based%20authoring%20and%20,exact=annotation,suffix=%20platform%20with%20built-in%20support%20) http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto... A screenshot/how-to: https://twitter.com/csarven/status/981924087843950595 https://twitter.com/csarven/status/981924087843950595

fock 8y ago
Typical GOOG move. Add some code, break the web outside the Google way. Why can't those guys write an RFC "Content sublocator-protocol for diverse media"... Well, I started writing this and read your answer. This is not a problem specific to html/the web, for example I regularly encounter this when referencing things in pdfs. Will definitely have a look at this!
ru999gol 8y ago
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
- raimue 8y ago
  The W3C design seems to be extensible for future use cases with a consistent syntax while keeping everything under one keyword. Something like this could also be applied to other types of documents, not only to text. Let's say to quickly draw a highlight on an image or specify a page in a PDF document. While "#targetText=" is simple, it is not a generic solution.

DarkWiiPlayer 8y ago

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

fxfan 8y ago

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?

ped4enko 8y ago

wow

rajangdavis 8y ago

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.

fooyc 8y ago

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 8y ago
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

amitjam 8y ago

http://www.alerttips.com/ http://www.alerttips.com/

Abishek_Muthian 8y ago

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

donohoe 8y ago

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

deleted 8y ago

[deleted]

severak_cz 8y ago

Despite it's flaws I found this thing really useful. Much more useful (for user) than utm_source & fbclid which pollutes todays URLs. However, i think that the functionality should be in browser extension not browser itself.

ped4enko 8y ago

good news for UX

gioele 8y ago

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 8y ago
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
ben174 8y ago
I suppose it could be argued that the DOM might change on a page, but the text content is less likely to. We want deep links to the text content, not the DOM element.

dak1 8y ago

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.

givinguflac 8y ago

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

iamapipebomb 8y ago

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

or113 8y ago

I actually wrote a really similar extension a year ago, please give me feedback! https://chrome.google.com/webstore/detail/target-search/nohmjponpgbnhjokbmagdbnjpnmdaigb https://chrome.google.com/webstore/detail/target-search/nohm...

jeena 8y ago

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.

nscalf 8y ago

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.

aesthetics1 8y ago

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.

moogly 8y ago

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.

Proven 8y ago

Very helpful... to Google's monetization of those who share links that way. I think I'll pass.

sasasassy 8y ago

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.

brokenmachine 8y ago

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.