ScrollToTextFragment

Which is exactly why we build an experiment first, to find potential issues before shipping. 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 https://github.com/bokand/ScrollToTextFragment/issues or https://crbug.com/new

Feature author here. I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a draft spec (W3C,WHATWG) at least some support from other vendors. Sorry, the explainer text came off more dismissive than I intended. I wanted to get something implemented so we could start experimenting and see how this would work in the wild. #targetText= is a a first attempt at syntax, any criticisms or data on how this might break would be appreciated. From my (limited) understanding of how fragments are used like this today,

Feature author here. The CSS timing attack actually influenced the design process heavily. The original design was to use a stripped down CSS selector but we found this too large of an attack surface. There's definitely still concerns around making sure a 3rd party can't exfiltrate information from the page using this but we think we've found a set of restrictions that should prevent this: https://github.com/bokand/ScrollToTextFragment#security

"Integration with W3C Web Annotations" https://github.com/bokand/ScrollToTextFragment/issues/4 > 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?

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, in