Cannot link to text snippet starting with hyphens (ASCII 0x2D) as common in CLI arguments

[porg]

User Goal

I want to link to a text snippet starting with 1 or 2 hyphens (ASCII 0x2D), as common for Unix command line arguments.

Problem

Linking to an online manpage and to a text fragment starting with 1+ hyphen(s), e.g. to -o or --output, does not jump to that target although that text snippet exists on the linked webpage.

Environment

• macOS 11 Big Sur
  • Safari 16.5
  • Chrome 114.0.5735.198

Examples

https://x265.readthedocs.io/en/master/cli.html#:~:text=--zones

• Text fragment URL
• ✅ Opens top of page.
• ❌ Does not jump to text snippet.

https://x265.readthedocs.io/en/master/cli.html#quality-rate-control-and-rate-distortion-options:~:text=--zones

• Intact fallback anchor link plus text fragment together in one URL.
• ✅ Jumps to anchor link, so the fallback at least works.
• ❌ But does not jump to text snippet.

https://www.ffmpeg.org/ffmpeg-all.html#:~:text=crf

• Searching for text snippet without dash prefix
• ✅ Matches in chapter 16.7.1 Options in mid sentence "... otherwise if crf is set ..."

https://www.ffmpeg.org/ffmpeg-all.html#:~:text=-crf

• Searching for text snippet with dash prefix
• ✅ Opens top of page.
• ❌ Matches nowhere although there is a code snippet with "-crf" within chapter 44.4.1 Examples.

Research

• The minus character must not be escaped according to https://github.com/WICG/scroll-to-text-fragment/issues/194#issuecomment-1219951592

Suspicions

• Maybe that prefixed 1-2 hyphens is&are colliding with text fragment's prefix-, function?
  • Seems unlikely to me, as there's another comma.
• Or maybe the browser vendors simply did not expect a text snippet starting with punctuation characters, and the parser does not handle that currently?

Followup

• I hope that linking to hyphen prefixed text snippets as common in command line arguments gets supported, because it's an easy measure to target exactly those and not a natural prose word.

[bokand]

This is supported but - must be percent encoded since it is used as part of the text fragment syntax. E.g. https://x265.readthedocs.io/en/master/cli.html#:~:text=%2d%2dzones

The minus character must not be escaped according to https://github.com/WICG/scroll-to-text-fragment/issues/194#issuecomment-1219951592

Perhaps you misread the comment? (I could have phrased it more clearly...):

The set of URL code points, less &, -, ,, can be used without percent encoding. All other code points must be percent encoded.

Means all you can use any URL code point other than &, -, , without percent encoding but &, -, , must be percent-encoded.

I'm going to close as I think this is working-as-intended but let me know if I missed something.

[porg]

Thanks for looking into this!

… URL code points, less &, -, , …

• Indeed: I had missed the "less" in front of the hyphen!
• Also: Safari and another web app which I used for URL encoding strings both left the hyphen as-is. Which is OK for URLs but not for text fragments, which have slightly different escaping rules as I now learned. This behavior had further lead to my false understanding.

Safari does string escaping of the text fragment in the address bar partially wrong

I reported this as a bug to Apple: Safari performs string escaping of text fragment in address bar partially wrong: Hyphen and Ampersand MUST be escaped but are NOT (FB12522049)

Pasting different strings into the text fragment of the URL in the address bar on ENTER performs encoding, but not always correct:

• ✅ one two gets one%20two
• ℹ️ one, two in the address bar shows as one,%20two in the UI which would fail, but I guess "behind the scenes" the comma actually is encoded as one%2C%20two. Because Safari correctly jumps to and highlights the full string.
• ❌ one & two gets one%20&%20two so falsely will only match one%20.
• ❌ one-two remains one-two so falsely will only match one.

Screen Recordings

https://github.com/WICG/scroll-to-text-fragment/assets/737143/db1571dd-e7dc-43f7-ac80-4a9626d84d2d

https://github.com/WICG/scroll-to-text-fragment/assets/737143/a2110251-d0e9-44ad-8c3e-07a66617c2a8

https://github.com/WICG/scroll-to-text-fragment/assets/737143/d174181e-b92e-4229-8f31-fb2070236b3a

[bokand]

Browser UI isn't standardized behavior so Safari may or may not choose to make changes there - that said, I'm not sure their encoding behavior is wrong (I think Chrome behaves the same way?), it depends on context. E.g if you paste:

example.com#:~:text=foo&text=bar

If the ampersand (&) is escaped this is a text directive to foo&text=bar whereas if it's not escaped it's two text directives, the first to foo and the second to bar.