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. 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). 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...
I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a draft spec (W3C,WHATWG) at least some support from other vendors.
Sorry, the explainer text came off more dismissive than I intended. I wanted to get something implemented so we could start experimenting and see how this would work in the wild. #targetText= is a a first attempt at syntax, any criticisms or data on how this might break would be appreciated.
From my (limited) understanding of how fragments are used like this today, the way this would break a page is if the page itself was using "targetText=..." and parsing the result. This is something we can and will measure and see if we have a naming collision. For pages that use a "#var=name" type fragment, we could append "&targetText=...".
I'm not tied to any particular syntax here so if I'm missing why this is a monumentally bad idea, please file a bug on the GitHub repo: https://github.com/bokand/ScrollToTextFragment/issues
That said, it seems easy to make this backwards compatible: if the existing #blah syntax is a valid link, that should take precedence.
FWIW, I think there's way too much cynicism in this thread. My first reaction on seeing the title was "cool! I would use that!".
edit: Hmm, I may have misunderstood the compatibility issue.
That's indeed how it works. The majority of the compatibility concerns appear to be with apps that a using _custom_ parsing of the fragment to perform app-specific logic, which is a valid concern.
- How does this perform on existing pages
- How does this feel from a user perspective
- How can I write pages that user this
Specification-up-front is very theoretical in the absence of an implementation. IMHO, where it's (rarely) happened in practice, the specification is often unimplemented. The value of a specification is that it allows other browser vendors to add an interoperable implementation.
Again, I'd like to stress, this is in the very early-stage experimental phase. We aren't dropping a feature that'll break the existing web.
Edit: To clarify, "implementation" does not necessarily mean shipped to users.
Literally just today we got an article about Web Bluetooth on the front page of HN, a user-shipped capability in Chrome that is still in the Draft phase of standardization.
Beyond that, we have the Web USB API, which is also in the draft phase, but is of course shipping to users in Chrome, on by default.
Beyond that, we have HTML imports, which have been rejected from the standard but are still shipping to users in Chrome.
I don't doubt your intentions, but if you think that Chrome is going to wait for standardization on this before it ships, you are not paying enough attention to the teams you're working with. And once Chrome ships a feature to users, the web standards body has basically two options: accept Google's vision of the standard wholesale, or change the standard and break websites that are already using Google's implementation.
I would be more confident and trusting of the process you describe if there was some kind of official commitment from the Chrome team that this feature will stay behind a browser flag until the standardization process is completely finished. But I think some of the reason you're getting immediate pushback to an extremely early draft of the spec is because developers don't trust Google not to ship this on-by-default once it reaches a WD stage.
Microsoft did this many moons ago. People ended up defacing web sites like the New York Times and spreading proto fake news.
You're going to get people generating millions of these links around the web. That's a long term legacy of hyperlinks generated by the citizens of the web. Although the fallback is obviously pretty harmless, what about a future feature? If this doesn't work out, but some other feature down the line does, suddenly thousands of these links start working in weird ways. Or worse, the feature doesn't happen at all, because of the legacy of broken links. I know that's pessimistic, but URLs are the foundation of the web, changing how they work should be funneled through the spec.
I think the reason this sparked concern is because (by using fragments) this intrudes into a field that was previously under full author control.
I think clear guarantees about which aspects of a webpage are the responsibility of authors and which are under browser control are important - only going by real-world usage and assuming everything not directly used is free for the taking is not enough here.
E.g., I think there are failure modes for SPAs that are not easily found with a usage search.  Additionally, this would make it harder to know for new applications which kinds of fragment identifier are "safe" to use and which are not.
There seem to be some existing specs that deal with the same problem .
Maybe those could be a starting point for the feature to to forward without interop/responsibility problems?
It’s an exciting possibility to link more directly to resources. I hope it is implemented in such a way that all browsers can follow those links with parity in the future. If that is the case I have a few hundred thousand outlinks that could be refined for clarity.
To be clear, I agree that this format is exceedingly unlikely to collide with real fragments, but still seems like there is a safer approach.
To the fragment. Tt could, depending on how the app was written. Is there a framework or some common techniques that use this I could read-up on?
I work in analytics so I’ve seen things like UTM params get couched into the hash, breaking parsing, so at least it’s something to keep an eye out for.
You can claim to have high standards, but Google is trying to dictate the future of the web.
So what they're saying is, they expect a clash of their abuse of URL fragments with others' abuse of URL fragmentsto be rare because...
The arrogance here is astounding: "It's OK for us to use this, because others shouldn't be using it"
Normally, url fragments were intended to be used by page authors, making clashes impossible (page author controls both page and anchor syntax). Google are breaking this contract, but argue that the fact that they're using parameter-style syntax should not clash with author usage, because using parameter-style syntax is "an abuse" of the feature.
To double check, does this means things like,
I haven't thought that much about the next part, but how do people feel about the following?
Page authors are unlikely to use web+text: if it means cutting off old browsers from access.
Why not "##" as a new URL fragment, or add a "scrollto" to the link tag that the browser can use?
I guess those were discussed, is there an RFC?
That was the pre-SPA, traditional role of anchors...
If you did any html between 1995-6 and 2005, you'd use it for that.
Then, with AJAX/SPAs, # was used for state (pre-history API) -- and I'd assume many webpages are still left at that use.
I just finished a large healthcare web site that uses page anchors.
Page anchors are recommended by one of the (many) federal web accessibility guidelines. This is so that people with limited motion or poor motor control, or visual impairments don’t have to scroll to find what they’re looking for on a page.
It’s also how the “Skip to content” links work, which is Accessibility 101.
Sorry, I’m not at work or on a computer so I can’t link to a reference.
Google's influence is massive, anyone wanting to build a profitable website needs to bend to their standards of performance and structure.
Normally this was a general push in the right direction for everyone. With how they've been handling AMP however, part of me wonders if they're not trying to build a feature moat around the web itself. Although misguided use of their power by individual product-managers is probably the less sinister, more likely reason.
I think it was called "Angular".
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.
It does require more coordination between the front and back-end though.
Would you just look at who's preaching... If it ain't the same Google that all but standardized the use of #! contraption in the pre-HTML5 days - "you don't use, we don't crawl it" kinda thing.
This is an abuse alright, but a better choice of wording might've been appropriate.
It is important to note that this won't break your site/app in the normal use case. People using your work will continue to do so uninhibited unless/until they wish to use this new feature in Chrome.
That way both could live together, if the page uses # in the fragment, just percent encode it.
At most this would break old bookmarks.
I would expect that it’s possible for both to work since Chrome’s hack requires the equal sign and its parameters. So with no equal, works as spec. With equal works with hack (that will likely make it into spec).
Even when a page has the targetText anchor and receives the text link param, I think the desired user behavior is to link to the text, not the anchor.
In other words, even if you give an element "id='targetText=something'", this feature wouldn't break that.
If you do see a page that you think might break and you're on Chrome newer than 74.0.3706.0, try turning on chrome://flags#enable-text-fragment-anchor and giving it a try. If something looks out of place, that would be extremely useful data for us. File a bug either at
Also, this would require the "targetText" parameter to live peacefully alongside other parameters. (That in turn would require there were a standard definition of "parameter" inside the fragment at all)
E.g, if Chrome encounters an url with an existing fragment, it would somehow have to combine this with its own targetText parameter and hope the SPA still understands the combined fragment.
Hash isn’t used for query parameters.
For example, look at the URLs used by mega.nz, or any encrypted pastebin (they store the decryption key in the hash so it's not sent to the server).
But not for query parameters per se, for app state stored in the query string (and bookmarkable).
Gmail used, others used it.
They could just be perfectly written (for their time), just legacy and not updated, is my distinction.
That's not true. Truth is:
> We'll just completely change the commonly understand processing model of fragment identifiers, it may not be fine, but can you really stop us?
W3C Reference Note on Selectors and States:
It is part of the suite of specs that came through the W3C Web Annotation Working Group:
More examples in W3C Note Embedding Web Annotations in 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/ clientside application:
Regarding URL hash abuse elsewhere: this current development in Chromium is different from front-end frameworks and specific websites doing it because SomeSite can't break OtherSite while both having a different way to handle the hash.
Now Chromium randomly claims part of the hash which others now need a workaround for? Are these devs serious?
edit: dear downvoter, explain yourself :)
Absolutely! Launching a change to the web platform is a long, arduous process. This feature is currently taking the very early first steps.
For more details, see https://www.chromium.org/blink/launching-features.
Having some feature like this for the web would in itself be good, just claiming a key in the hash part just for this would (and I know that hash doesn't really have a format so "it's not a key" etc, but it does gets used that way).
A proposition: instead of using plain 'targetText' how about having some prefix for all Chromium's claims in the hash part so that the front-end (framework) developers can filter these out without needing to keep a list?
> ... and make half the world use it.
> Add about:flag for Scroll-To-Text
> Adding chrome://flag to allow users (particularly on Mobile) to easily enable and test the feature.
(Commit message via https://chromium-review.googlesource.com/c/chromium/src/+/14...)
So nobody will use the feature unless they explicitly choose to.
> It would be great to be able to comment on the linked resource text fragment. W3C Web Annotations [implementations] don't recognize the targetText parameter, so AFAIU comments are then added to the document#fragment and not the specified text fragment. [...]
> Is there a simplified mapping of W3C Web Annotations to URI fragment parameters?
Please note that you've actually changed the example!
If you just want to include `exact` or "targetText", you can still do:
but that selects all instances of the text "annotation" in the document. Which is precisely why we need `prefix` and `suffix` to be able to identify the actual selection that the user made.
So, here is the equivalent of your example:
I hope that clarifies.
This is just tip of the iceberg! Let's stick to fair comparison and consider extensibility.
Please have a closer into why we should be mindful of different use cases here, especially those pertaining to different resource representations, ways to "select", and factor in the state of the resource/representation at the time of the selection. It is there for use. It doesn't mean that all possible options needs to make its way into the identifier. This is important because people are going to use these identifiers in documents, and preserving context matters. Like I said earlier, the W3C Note has considered these, as well as permitting the use of different (RFC) selectors for different media. Let's reuse instead of NIH-FUD.
There then remains the question of cross-compatibility: do all relevant tools implement the same techniques? That is a legitimate concern, but it’s well-enough specced that it shouldn’t be a problem.
Also as noted, various tools out there already use this format. The Chrome team ignoring that and using their own, functionally inferior format is hostile.
There is a reason nobody implemented the W3C proposal, If I have the choice between a simple working solution that anyone can describe in a single sentence specification and a hundred page specification with tons of unneeded features that nobody is going to implement ever, I choose the former. I wonder how much hate Mozilla would've gotten for the same feature, probably none.
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!
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>)
Pointer to all occurrences of "target text" in a <p> in the <main> article
* Pointer to the second <h2> heading
* Pointer to that specific bullet point that you want your colleague to change ASAP
* Abbreviated fall-back to XPath
See also https://news.ycombinator.com/item?id=19169582
- 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 (where some actual data wouldn't hurt, btw)
- The linked proposal 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?
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.
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.
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
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.
> 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. The following example identifies lines 11 through 20 of a text document:
Expanded here: https://news.ycombinator.com/item?id=19169582
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.
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.)
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.
I really don't understand what this brings to the table, besides making people upset.
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.
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.
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.
Despite all the suggestions of "browser wars", they're actually very friendly and collaborative.
> 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 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.
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.
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.
Browsers copy features from each other. If this is a useful feature, it would make its way to other browsers pretty soon.
We're really far from IE6 era of complete stagnation.
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!
And that is bad exactly why?
> 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
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.
It was good while it lasted.
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.
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.
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.
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.
They already started doing part of this plan btw - https://bugs.chromium.org/p/chromium/issues/detail?id=881410
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 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". 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.
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.
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.
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
Link to first occurrence of "pseudo" on page:
Link to last occurrence of "highlight" on page:
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/
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
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.
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.