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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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).
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.
Perhaps it could automatically expand the selection until it becomes unique, and support an index property for cases in which that would result in an unreasonably large selection (or hits EOF).
Using indices alone would also work, but would be exceptionally prone to link rot as text changes, especially in the case of short (e.g. 1-word) selections.
They could fix this by having a second query string parameter, say, "targetInstance". Which would take the number of the instance. Indeed, things like this would have come to light sooner if they went through a more normal RFC process.
This whole thing is messy and fragile by its very nature. I'd argue that if you have to get as fancy as linking to the second instance of a string, then your odds of the link going to the right place later are not that great anyway. So it might not be worth even trying to solve that problem.
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.)
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.
That depends on the author annotating their page with ids so it's highly content dependent. In addition, authors can't always predict what will be interesting to users and pages frequently don't have IDs on elements you might want to link to; this is particularly true of long passages of text.
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.
> I don't think many articles have a lot of repeating sentences.
This misrepresents the comment you're replying to. The case I gave was "linking to a single word." Articles have a lot of repeating words.
I can see users highlighting and linking to a key word or two in the section they want to link to. This is going to result in a broken link if it's not unique. This is not an edge case. It's not even mentioned as a potential issue in the spec.
Should the browser at least warn that this is going to result in a broken link as the doc currently stands? Should it disable the feature until sufficiently unique text has been selected? Should it just silently let you copy a broken link and chalk it up to PEBKAC (which is what the spec seems to imply)?
Perhaps it could actually prefill the standard find dialogue and scroll to the first match, then you could easily see if there was more matches and jump to them.
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)
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.
> 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.
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-conver...
What does that even mean? AMP is built on WebComponents, which are an existing web standard. That's no less standard than anything else using custom elements.
Nowhere in the standard "higher search ranking on google inc" is mentioned as a must have feature. Yet it is the only feature anyone care about when discussing adoption.
If that were true (and I'm not so sure it is), then you'd blame the search team for letting it be a ranking factor. It has nothing to do with web standards.
You are not wrong (about what is on the standards). But you are being downvoted because everyone who did implement AMP in the real world, did so for the SEO benefits.
Oh I have votes disabled on social media. I'd rather form my own opinion when reading comments.
Regarding AMP, I appraised it from a speed perspective and found it partially effective, but only a bandaid fix. Addressing real site speed issues is the better approach.
They are caching a chunk of the web and routing traffic from google.com to their cache. Since traffic never leaves google.com, it is now in a way the web itself. This is achieved thanks to AMP.
Technically that's AMP Cache, not AMP itself, but I get your point. It's worth noting however that both Cloudflare and Bing also run their own instances of AMP Cache.
No, no, Microsoft was the old Microsoft but now they're the new Apple. Google is the new Microsoft, and Apple looks like the new Google but is actually the old Apple (the old one, mind, not the middle one where Jobs came back). Oh, and Dell is the new Gateway. :P
if you don't specify a timeframe you can't be contested and therefore your nostalgia reads like it is for a time that never existed except in your mind
Judging from this chart[1], definitely somewhere between 2008 (the x-axis starts at 2009, but if I recall correctly Chrome was released in 2008) and second half of 2012. Possibly the original comment was referring to a larger time span than this, but judging from the linked chart that's when Chrome was still on the up-and-up compared to IE. In my opinion though, this timeframe was 2008 to about 2014, when Google (and Microsoft) essentially strong armed Mozilla into accepting EME[2]. I'm not sure that's when the slippery slope really started, but it's definitely when I started believing there's a new boss in town – same as the old boss.
I remember writing websites at that time. Developers were worried about there being "yet another browser to support". It was a big deal because supporting all the browsers was already a lot of work. Nothing rendered consistently. Javascript would run fine in one browser, but not in other. You got to deal with fun features like quirks mode and worrying about transparent pngs. You had to use Flash if you wanted to embed a video.
The web is a completely different place today. Everything renders consistently across the different browsers - even Edge for the most part. Javascript is a modern language now. Video/audio embeds were finally standardized. Layout tools are significantly better with flexbox and soon, grid.
The idea that we were at some web standards pinnacle in 2008-2012 is crazy to me. The pinnacle is now.
> The idea that we were at some web standards pinnacle in 2008-2012 is crazy to me. The pinnacle is now.
I don't think the point was that we were at a pinnacle in terms of standards quality, completeness, or user agent consistency. Rather I think the point – at least it for me – was that during those years it was more of a conversation, not Google choosing a direction and everyone else more or less forced to follow suit. We are certainly in a better spot today in terms of capability, I agree, but I'm not sure I'd agree that we're in a better spot in terms of collaboration.
At what time has there been better collaboration between browser vendors than right now? That is the reason that browsers are so well in sync with each other now.
Well that's the argument, isn't it? Collaboration doesn't mean necessarily mean being in sync or following suit. When there's a hegemony then a level of collaboration might still exist, but if the interests don't align with the dominant party they can just go ahead anyway and more or less force others to fall in line – e.g. EME. Even if everyone syncs up, it's not necessarily good collaboration. Conversely, the dominant party can choose to just ignore other's contributions and ideas if their interests don't align, effectively making those contributions largely pointless.
Whether or not you agree is one thing, but I hope my point is clearer now anyways. :o)
Thanks for being respectful and well-reasoned in your response.
My opinion is that the collaboration is probably the best it's ever been right now. The example I gave lower down in this thread is that when WebAssembly was introduced, the Chrome team decided to deprecate their own solution, PNaCl.
> Thanks for being respectful and well-reasoned in your response.
Likewise!
WebAssembly is a very good counter example, but still my feeling – or fear, really – is that this is not in spite of Google's hegemony but because of it. Let's say they hadn't gotten on board with WebAssembly and instead doubled down on PNaCL or come up with a different competing proposal. Even if all other parties rallied around WebAssembly there's a very good chance the dominance of Google would make it stillborn. If it's not in Chrome, it's simply not worth bothering, purely due to its dominance.
I recognize though that this is a bit of a straw man argument, and one based more in my opionins and feelings in the matter rather than anything resembling objective truths. I suppose that's also why we'll have to agree to disagree. :o)
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.
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.
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.
One thing I’ve discovered from learning and using Common Lisp seriously is that it’s really important for a system to be specified in a way that allows for extensions to the system to be implemented in terms of primitives the language provides (e.g. you want a new language construct, write a macro to transform your desired syntax into Common Lisp). In languages and systems that don’t have this feature, an implementation that introduces useful extension begins to develop lock-in and makes it harder to compete. (E.g. no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions.(
)
There are significant tradeoffs between shared constructs and self contained systems. Self contained systems resist ossification; they can be unilaterally replaced. A shared construct has to evolve in step with all of its users.
But the self contained system will have thousands of incompatible implementations, and the shared system will be easier to interact with and build on top of.
What this means is that a browser should standardize on things meant to be interfaces, and leave out all of the rest. Unfortunately, they didn't and now browser engines are huge and impossible to evolve except by adding more stuff.
Similarly, the value of programming languages is almost entirely in the interfaces they provide which allow you to develop code. Lisp provides almost none of that, and that is why it failed to become mainstream.
> no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions
This is a bit of a misconception. One can still write Haskell98 whilst using a library that use a GHC-specific extension. The library doesn't (have to) force its consumers to use extensions too!
I phrased that a bit wrong: my experience (from talking to the Haskellers in my company) is that Haskellers generally prefer to turn on a bunch of extensions when they write code. So, while you might be able to write pure Haskell98, it tends not to be idiomatic to do so.
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.
I don't see how this supports to the argument that you can easily build a new, competing browser by forking. If you fork and then need the same kind of resources to replyce the forked codebase with your own, I don't see what you'd win.
Competition that spurs innovation is good, more like, but I am skeptical of the claim that competition is necessary to prompt innovation, and whether the costs of such a model (leading to massive waste of society's productive capacity) are worth the purported benefits. For instance, a good deal of mathematics and science was not done on the principle of competition, but search for improvement. The real question is whether the development in goods and services can be or could have used similar principles, which is not only more efficient but seems condusive to better mental well-being; I'd rather desire to improve than to slight (and possibly sabotage) someone who must be my opponent.
Is a browser really a "wheel"? There are so many choices to make, so many lines drawn in the sand. And besides, you really don't want the marketing and tracking giant Google to make all the decisions regarding the software that delivers so much content to billions of users' screens, do you? They've been okay so far, but there's a huge conflict of interest here.
It's not just a browser feature, now is it, it's an interoperability feature since you're supposed to share links (it's in the title). This means that the near-monopoly is going to drive people who receive the shared link to consider using the browser that supports this. That puts other browsers quite on the defense, does it not?
It sounds not unlike what used to be the role of W3C before HTML5. Everything stagnated, while Microsoft with IE largely did not care, and everyone ended up making their pages in Flash because it was the only really consistent target.
Because we've all been heavily brainwashed in to requiring constantly "new" stuff. It's going to take a World changing event to break us out of that cycle IMO.
Do you actually follow spec discussions, or are you just guessing? From what I have observed the Chrome, Firefox, and Safari teams are in constant communication. They discuss new features, implementation details, and potential pitfalls.
Despite all the suggestions of "browser wars", they're actually very friendly and collaborative.
Nevertheless it's some kind of fait accompli, especially in a market with only three main actors.
Where one actor can also start using the new "standard" overnight and break lots of services for people which are not using their browsers... You know what I mean. It's some kind of enforcing to have a monopoly.
> It is most likely that this will be added to other browsers like Firefox too.
> Microsoft’s new version of Edge is going to be based on Chromium, so this will be available on Edge too.
So, although some discussions with Firefox may have begun, it's clearly using the Microsoft decision to use Chromium as a way to force their standpoint. Note also the lack of mention of Safari.
This is the kind of stuff that should go thru a central committee because different browsers will react differently to what should be a simple url.
I've followed a few directly, and as a web developer I generally have my ear to the ground for these things. It's possible this feature was discussed, but the article made it sound like it wasn't in a formal capacity, and I know for a fact that Google has forced things through in the past, even when there's been active protest from people at Mozilla. And that was while Microsoft still had their own engines.
That’s exactly what I would do in the same shoes I think. Proposals are cool and I understand why it is better for an open web etc… but getting features immediately is pretty cool too.
But then they only work in one browser and that is massively uncool.
So yeah, standards please. And not Googley “Comments? What do you mean ‘comments’? We’ve already shipped this and we’re not changing it, so you better follow suit”-standards.
web standards are descriptive not prescriptive, and have always been: nobody asked before adding the <blink> tag to their web browser, it was just added (and later removed) after it was used by more than one implementation and consensus was found how it's supposed to behave.
For example, WebSQL died because there was only one implementation: implementations come before the standards.
In the W3C process, a Working Draft can be written before any implementations. Even a CR doesn't need to have been realised. To progress to PR and Recommendation, it needs to have implementations.
WHATWG is more descriptive, HTML 5 has been described as a collection of everything Hixie has seen somewhere on the web and thought cool.
Still, it's nothing new that browser vendors just add the things they think may be useful and see what sticks (which then eventually ends up in some standard at some point like asm.js/WebAssembly - or fizzles out like NaCl).
These days with vendor prefixes, polyfills and generally a focus on backward compatibility there's typically some care taken to not leave users of other browsers in the dust.
That's very different from past efforts like, for example, ActiveX which made a full (but undocumented) Win32 environment part of the web browser design.
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.
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?)
"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
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.
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.
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.
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.
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?
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.
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.
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.
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.
“#” 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.
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.
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.
Honest question: is there a specific person who is smugly grinning about this at google.
Like the people at FB who run around thinking how awesome they are for coming up with a new spying technique and what idiots the world is for not recognizing their innovation?
> Honest question: is there a specific person who is smugly grinning about this at google.
I sort-of understand where you're coming from, but isn't this needlessly hostile? Unlike in the case of "spying innovation" you brought up, Chrome's "Scroll to Text" seems to be intended with the user's benefit in mind (and only indirectly Google's — via greater user satisfaction, but that's exactly the product design model we want).
It would have obviously been far preferable if this had gone through the "proper channels" (discussion at the W3C, standardisation etc. first), but I don't think that there's any evidence to believe that anybody at Google thinks that they're the first to come up with this.
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... ¯\_(ツ)_/¯
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.
> 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)
They use the same trick for Google Search in a way that is transparent to the user - as long as you have JS turned on. When you switch it off, you realize instead of clicking on HNs URL, you actually click https://www.google.com/url?q=https://news.ycombinator.com/&s...
Now, they want to move a step further. I wonder when they're going to stop.
This technique (redirecting through some dummy ?url=... page) is a common way of doing an external redirect on any service you're building. It's a simple way of making it impossible to see the actual Referer to external website, which is more secure to your data and the service you're building (e.g. Gmail).
Code usually doesn't carry final HTML in its data structures, whereas converting a URL in a single place where it's extracted is easy. In other words, making sure you didn't miss to put rel=noreferrer everywhere is way harder.
Because I've done tracking like that for several years, lots of services are still doing it this way and because rel="noopener" or rel="noreferrer" is the way to go if you want to mask the referrer. Even Google recommends to do it that way[0].
If you are not using it for tracking, there is no point in doing it like this after all.
Actually, it seems like the <a> you click on Google Search has the right href (which is what appears on the status text) but it also has a ping attribute to it for tracking.
Nobody cares, really, except for a percent fringe users of a percent of Google users.
On a more general point, once again Google Search is provided to you for free. If you don't want to use it by their rules, you are entirely free to use Bing or Yahoo. Actually using the service regularly, because it is tailored to your workflow and provides value to you, while complaining that the tailored/value-adding part is driven by an analysis of your behaviour on the servicee... that's very hypocritical.
I don't use Google, I use StartPage. I am plainly stating that I am surprised nobody made an extension to remove the ping= link attribute from all webpages, considering that the only reason it exists is to track user activity.
That is exactly what is hypocritical about your behaviour: Startpage exclusively uses results from Google, which the company pays Google for. So you are using Google regularly while complaining about it.
> 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
I understand the skepticism about Google's motivations but "making Chrome better and more feature rich so people will want to use it" is completely in line with Google's business plans.
I believe you. That's what the fine folks at the IE team did with ajax too, for example. And I am not being ironic, but the line is so thin that I have to point it out either way.
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.
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.
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.
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.
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.
» 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
331 comments
[ 1.2 ms ] story [ 436 ms ] threadBut 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.
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.
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.
> 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
https://en.wikipedia.org/wiki/Fragment_identifier
Expanded here: https://news.ycombinator.com/item?id=19169582
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.
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
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.
Plus, you can always select more text.
Usually the same phrase is not repeated in the text if you select more than 1-2 words.
Using indices alone would also work, but would be exceptionally prone to link rot as text changes, especially in the case of short (e.g. 1-word) selections.
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.)
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
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.
This misrepresents the comment you're replying to. The case I gave was "linking to a single word." Articles have a lot of repeating words.
I can see users highlighting and linking to a key word or two in the section they want to link to. This is going to result in a broken link if it's not unique. This is not an edge case. It's not even mentioned as a potential issue in the spec.
Should the browser at least warn that this is going to result in a broken link as the doc currently stands? Should it disable the feature until sufficiently unique text has been selected? Should it just silently let you copy a broken link and chalk it up to PEBKAC (which is what the spec seems to imply)?
Needs more thought IMHO.
> 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.
That’s not really the point
Nowhere in the standard "higher search ranking on google inc" is mentioned as a must have feature. Yet it is the only feature anyone care about when discussing adoption.
Regarding AMP, I appraised it from a speed perspective and found it partially effective, but only a bandaid fix. Addressing real site speed issues is the better approach.
https://amp.cloudflare.com/
https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu...
They already started doing part of this plan btw - https://bugs.chromium.org/p/chromium/issues/detail?id=881410
It was good while it lasted.
[1]: https://en.wikipedia.org/wiki/Google_Chrome#/media/File:Web_...
[2]: https://hacks.mozilla.org/2014/05/reconciling-mozillas-missi...
The web is a completely different place today. Everything renders consistently across the different browsers - even Edge for the most part. Javascript is a modern language now. Video/audio embeds were finally standardized. Layout tools are significantly better with flexbox and soon, grid.
The idea that we were at some web standards pinnacle in 2008-2012 is crazy to me. The pinnacle is now.
I don't think the point was that we were at a pinnacle in terms of standards quality, completeness, or user agent consistency. Rather I think the point – at least it for me – was that during those years it was more of a conversation, not Google choosing a direction and everyone else more or less forced to follow suit. We are certainly in a better spot today in terms of capability, I agree, but I'm not sure I'd agree that we're in a better spot in terms of collaboration.
Whether or not you agree is one thing, but I hope my point is clearer now anyways. :o)
My opinion is that the collaboration is probably the best it's ever been right now. The example I gave lower down in this thread is that when WebAssembly was introduced, the Chrome team decided to deprecate their own solution, PNaCl.
We're far from the days of ActiveX.
https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...
Likewise!
WebAssembly is a very good counter example, but still my feeling – or fear, really – is that this is not in spite of Google's hegemony but because of it. Let's say they hadn't gotten on board with WebAssembly and instead doubled down on PNaCL or come up with a different competing proposal. Even if all other parties rallied around WebAssembly there's a very good chance the dominance of Google would make it stillborn. If it's not in Chrome, it's simply not worth bothering, purely due to its dominance.
I recognize though that this is a bit of a straw man argument, and one based more in my opionins and feelings in the matter rather than anything resembling objective truths. I suppose that's also why we'll have to agree to disagree. :o)
> We're far from the days of ActiveX.
Thankfully!
Browsers copy features from each other. If this is a useful feature, it would make its way to other browsers pretty soon.
By golly, that's the problem right there.
But the self contained system will have thousands of incompatible implementations, and the shared system will be easier to interact with and build on top of.
What this means is that a browser should standardize on things meant to be interfaces, and leave out all of the rest. Unfortunately, they didn't and now browser engines are huge and impossible to evolve except by adding more stuff.
Similarly, the value of programming languages is almost entirely in the interfaces they provide which allow you to develop code. Lisp provides almost none of that, and that is why it failed to become mainstream.
This is a bit of a misconception. One can still write Haskell98 whilst using a library that use a GHC-specific extension. The library doesn't (have to) force its consumers to use extensions too!
We're really far from IE6 era of complete stagnation.
And that is bad exactly why?
Despite all the suggestions of "browser wars", they're actually very friendly and collaborative.
So far I think that's been a good think on balance because they are good technologies. But it is worrying how much power Google has in this space.
WebP is a file format and doesn't fall into the normal standardization process. Browsers implement support for new file formats at their own behest.
Where one actor can also start using the new "standard" overnight and break lots of services for people which are not using their browsers... You know what I mean. It's some kind of enforcing to have a monopoly.
You'll note that they're also willing to kill features which are not adopted, like PPAPI.
After adding whitelists for Google properties like Hangouts, of course.
> It is most likely that this will be added to other browsers like Firefox too.
> Microsoft’s new version of Edge is going to be based on Chromium, so this will be available on Edge too.
So, although some discussions with Firefox may have begun, it's clearly using the Microsoft decision to use Chromium as a way to force their standpoint. Note also the lack of mention of Safari.
This is the kind of stuff that should go thru a central committee because different browsers will react differently to what should be a simple url.
So yeah, standards please. And not Googley “Comments? What do you mean ‘comments’? We’ve already shipped this and we’re not changing it, so you better follow suit”-standards.
For example, WebSQL died because there was only one implementation: implementations come before the standards.
In the W3C process, a Working Draft can be written before any implementations. Even a CR doesn't need to have been realised. To progress to PR and Recommendation, it needs to have implementations.
WHATWG is more descriptive, HTML 5 has been described as a collection of everything Hixie has seen somewhere on the web and thought cool.
Still, it's nothing new that browser vendors just add the things they think may be useful and see what sticks (which then eventually ends up in some standard at some point like asm.js/WebAssembly - or fizzles out like NaCl).
These days with vendor prefixes, polyfills and generally a focus on backward compatibility there's typically some care taken to not leave users of other browsers in the dust.
That's very different from past efforts like, for example, ActiveX which made a full (but undocumented) Win32 environment part of the web browser design.
While Chrome does useful stuff like this, Firefox progress in the web space is... eh... adding ads to the home page?
Maybe Firefox should've went with a proposal on how to add ads into the browser, or on how to send all of your URL history to a third party. :^)
But I can't link to a search phrase in a PDF. For some reason, they implemented searching for single words, but not phrases.
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.
http://rg3.github.io/youtube-dl/about.html
Link to first occurrence of "pseudo" on page: 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...
- 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...
[2]: https://github.com/bokand/ScrollToTextFragment#encoding-the-...
want to guess which one doesnt need JS, or server-side handling to work?
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.
Like the people at FB who run around thinking how awesome they are for coming up with a new spying technique and what idiots the world is for not recognizing their innovation?
I sort-of understand where you're coming from, but isn't this needlessly hostile? Unlike in the case of "spying innovation" you brought up, Chrome's "Scroll to Text" seems to be intended with the user's benefit in mind (and only indirectly Google's — via greater user satisfaction, but that's exactly the product design model we want).
It would have obviously been far preferable if this had gone through the "proper channels" (discussion at the W3C, standardisation etc. first), but I don't think that there's any evidence to believe that anybody at Google thinks that they're the first to come up with this.
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... ¯\_(ツ)_/¯
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?
Bonus: being its own site, and implemented in javascript, it's already cross-browser.
They use the same trick for Google Search in a way that is transparent to the user - as long as you have JS turned on. When you switch it off, you realize instead of clicking on HNs URL, you actually click https://www.google.com/url?q=https://news.ycombinator.com/&s...
Now, they want to move a step further. I wonder when they're going to stop.
It's about tracking outbound links, not about masking the referrer. As already mentioned, there are standard ways for that.
If you are not using it for tracking, there is no point in doing it like this after all.
[0] https://developers.google.com/web/tools/lighthouse/audits/no...
https://www.w3schools.com/tags/att_a_ping.asp
Edit: it seems to remove ping, but the onmousedown event is still there.
On a more general point, once again Google Search is provided to you for free. If you don't want to use it by their rules, you are entirely free to use Bing or Yahoo. Actually using the service regularly, because it is tailored to your workflow and provides value to you, while complaining that the tailored/value-adding part is driven by an analysis of your behaviour on the servicee... that's very hypocritical.
I understand the skepticism about Google's motivations but "making Chrome better and more feature rich so people will want to use it" is completely in line with Google's business plans.
[1] http://userscripts-mirror.org/scripts/review/8356 [2] https://developer.mozilla.org/en-US/docs/Web/API/Window/find
https://www.w3.org/community/openannotation/
Hypothes.is is a well established open implementation.
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.
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!
> 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