20

When Linking to a Text Fragment, a tilde character ~ 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 in Markdown, the tilde is escaped to %7E. In particular, this caused text highlighting to fail on three .gov and one .org sites that I encountered over a four day period. Today, I tested this on meta.stackexchange.com and had the same problem.

On StackExchange, text highlighting only works 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?


* - "Link to highlight" is a standard feature in Google Chrome, and is available as an addon for other browsers.

9
  • So, to clarify, links composed as HTML anchor elements (<a>) keep the ~ character unescaped, but Markdown footnote links do not. Does this happen with Markdown inline links ([link text](url)) as well?
    – zcoop98
    Sep 22, 2021 at 19:04
  • @zcoop98 - Didn't try it. I don't normally use that form.
    – Rick Smith
    Sep 22, 2021 at 19:07
  • 3
    It appears it's the same, inline links also escape the ~, breaking highlighting.
    – zcoop98
    Sep 22, 2021 at 19:14
  • See also: stackoverflow.com/a/62162093
    – Rob
    Sep 22, 2021 at 19:25
  • 1
    @Rick Just made a pretty substantial edit to try and improve the overall clarity of what's going on, and highlight specifically why the link isn't working. If you feel its too drastic, or strayed too far, please feel free to rollback or edit it to your linking.
    – zcoop98
    Sep 22, 2021 at 19:51
  • I just spent some time figuring out why I can’t link to MDN docs with the URL https://developer.mozilla.org/en-US/docs/Web/CSS/--*. Whenever I click on my link, I get a 404 page on the URL https://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 removes https: 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. Mar 6 at 23:52
  • Now, when SE converts my Markdown to HTML, it encodes the * 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 …/--%2A and replaces it with s/%/%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! Mar 6 at 23:52
  • Note: Scroll-To-Text Fragment is non-standard, but something like it will, probably, eventually be standard. It's primarily supported by Chrome and browsers based on Chromium, but not other browsers. So, while I agree that this should be supported in SE's backend conversion of Markdown➞HTML, it's debatable what level of priority this should be for SE.
    – Makyen
    Aug 3 at 17:37
  • I'd note that the issue could/should be considered a bug in Chromium, in that it's not recognizing :%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.
    – Makyen
    Aug 3 at 17:38

0

You must log in to answer this question.

Browse other questions tagged .