This assumes all SPAs would ignore unknown parameters they see in the fragment part. Even if the SPA itself doesn't use "targetText", it could still try to validate the fragment and abort with errors on unknown data present.
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.
I think he means it the other way around. You have a Single page application with routing based on #someRoute, then someone tries to share some link with the #targetText=... which will lead to an invalid route. Or am I missunderstanding something?
Backbone JS uses hash for routing. Case in point - http://backbonejs.org/#Router. There should be lot of sites that uses hash params as routes which still exists from the early SPA era.
lots of older or poorly written SPAs use the hash exactly in this way. I guess their fault for being poorly written, like those people who allowed GET requests to /deleteaccount based on the theory that you had to be logged in with a browser for it to ever happen and not considering that google would make an extension that did all get requests on a page on entry.
sure, it was state of the art back in the day, but state of the art over time depreciates to technical debt, and the ones that are left using what was once state of the art are now poorly written.
at some point the accretion of legacy and not fixing issues to match better understanding turns a perfectly written for its time application into a poorly written application for the present.
