When Linking to a Text Fragment, :~:text= is used as part of the URL to identify text to highlight:
https://meta.stackexchange.com/q/370143/#:~:text=to%20identify%20text%20to%20highlight%3A
When using a link like this on SE in posts using Markdown, the tilde, ~, is escaped to %7E. This causes Chromium to not recognize the :~:text= and text highlighting to fail. Today, I tested this on meta.stackexchange.com and had the same problem. Such links do work in comments and if the link is added as an HTML <a href=""> tag.
On Stack Exchange, text highlighting only works in posts when the link is created with HTML anchor tags (<a>), with the link specified in the href attribute.
| Link Type | Typed Text | Link Works? | Example |
|---|---|---|---|
| HTML | <a href="example.com#:~:text=test">text</a> |
Yes~ → ~ |
How do I search tags? |
| Markdown | [text][1]or [text](example.com#:~:text=test) |
No~ → %7E |
How do I search tags? |
Markdown links are much easier to interpret when composing a post, but tildes are escaped when using them, which causes the highlight feature to fail.
In a previous question, Link with underscore does not work, a problem with underscores (_) being escaped to %5F was noted and has since been resolved.
Could a change be made to prevent escaping the tilde character (~) in Markdown links?
* - "Text Fragments" is a, currently, non-standard feature which is implemented in Chromium (e.g. Google Chrome, etc.) and Safari. It was proposed a few years ago (2019/2020), but is not on a standards track. It is, however, slowly being implemented in other browsers, so something will likely end up being added to the standards. For Firefox, while Mozilla is generally positive on it, there's nobody working on implementing it at this time.
<a>) keep the~character unescaped, but Markdown footnote links do not. Does this happen with Markdown inline links ([link text](url)) as well?~, breaking highlighting.https://developer.mozilla.org/en-US/docs/Web/CSS/--*. Whenever I click on my link, I get a 404 page on the URLhttps://developer.mozilla.org/en-US/docs/Web/CSS/--%252A. I only noticed this because I have a userscript that shortens links in comments. My script removeshttps:so it becomes a protocol-relative URL — this works fine. But my script also removes/en-US— this works in virtually all circumstances, but it causes the MDN server to redirect to …/en-US/…. This redirect is usually not problematic.*as%2A. This is the same encoding as in this question — the one that should be prevented. Inspecting the link and doing.getAttribute("href")literally includes the%2A. Other Markdown–HTML converters, e.g. GitHub’s, don’t do this..getAttribute("href")literally preserves the*. MDN’s redirect, when adding the/en-US, unfortunately sees …/--%2Aand replaces it withs/%/%25/g, resulting in …/%252A. Yes, it’s broken, but it’s an example of the fact that URLs must not be assumed to be equivalent to escaped URLs!:%7E:text=as a valid alternate for:~:text=. Even the IETF RFC3986 section 2.4 says 'For example, the octet corresponding to the tilde ("~") character is often encoded as "%7E" by older URI processing implementations; the "%7E" can be replaced by "~" without changing its interpretation.' So, technically, this looks like a bug in Chromium's implementation. At a minimum, people will likely point fingers back and forth as to responsibility.