Broken anchors when header contains accents

[rehypejs]

Broken anchors when header contains accents

[wooorm]

Which one is wrong? What's the actual and what's the expected?

[github-actions]

Hi! Thanks for taking the time to contribute! This has been marked by a maintainer as needing more info. It’s not clear yet whether this is an issue. Here are a couple tips:

• Spend time framing the issue! The more time you put into it, the more we will
• Often, maintainers respond with why for several back and forths; rubber duck debugging might help avoid that
• Folks posting issues sometimes fall for xy problems: asking for a certain solution instead of raising the root problem

Thanks,
— bb

[michael-jeulinl]

Both are containing accents:
<a class="toc-link toc-link-h1" href="#title-efé">
<h1 id="title-efé">title efé</h1>

According to the specification : https://url.spec.whatwg.org/#concept-url-fragment
An URL fragment is ASCII-only (no "international characters" accepted directly).

The link containing the anchor #title-efé is broken.

[wooorm]

Both are containing accents

You should try this HTML out in a browser and observe that it works.

According to the specification : url.spec.whatwg.org/#concept-url-fragment
An URL fragment is ASCII-only (no "international characters" accepted directly).

You reference the URL spec, which defines URL objects, (and more importantly the reading part not the writing part), that spec does not define what values are allowed inside href on a in the HTML spec, nor how URLs work on the larger web.
Non-ASCII values are allowed in URLs, which you can observe by passing them to URL:

(new URL('https://example.com/#🤷‍')).hash // #%F0%9F%A4%B7%E2%80%8D

^-- this shows that the URL class reading that you linked supports non-ASCII characters as input, and creates the ASCII-only hash you linked with percent-encoding.

Practically too, in these projects we follow the algorithm that GitHub uses. GitHub uses those accents. If you feel that they’re horrible wrong, go take it up with them.

[iBobik]

I have the same issue - it generated this slug which does not work in Safari: "začneme-tou-prvn%C3%AD-otázkou-kdo-jsem"

Also here people mentioned similar issue in Firefox: nuxt/content#835

So it is not OK to have this characters in URL.

[wooorm]

The problem is nuxt. The problem is not this package. This package does not generate links. Using the IDs generated here in a URL is fine.

[iBobik]

I tried to copy ID from the code and paste is in a address bar, so Nuxt link have not been involved. Honza Pobořil 16. 6. 2022 18:13:00, Titus ***@***.***> napsal:

…

The problem is nuxt. The problem is not this package. This package does not generate links. Using the IDs generated here in a URL is fine. — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEV6WH2DCVIDTFTA34MJGLVPNHAZANCNFSM5SQZHE6A> . You are receiving this because you commented.Message ID: ***@***.***>

[wooorm]

Please make a reproduction. And read the thread. I tried that, it worked.

[michael-jeulinl]

Actually, I have found that the problem occurs when you pipeline rehype-slug with rehype-format.
Try removing rehype-format.

[wooorm]

Please make a reproduction. I don't believe rehype-format touches IDs