-
-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CJK link processing causes Markdown links and HTML links to have different URLs #672
Comments
The link from markdown still works though, right? You can open both and they go to the same place. Sounds like an issue in pa11y to me |
The links are equivalent, but there should not be reason to munge the URL to a different encoding (and code style) if it is valid as-is. |
Right, both URLs resolve to the same page, but it complicates any post processing that might be done after markdown. For example, if I have a static site and I grep for a Japanese link, now I have to search for two patterns, the original Japanese and the converted one. |
This isn't an issue with the spec, because the spec doesn't mandate that the URLs be escaped this way. That's up to the renderer. |
According to Babelmark3, CM implementations disagree on this:
|
Yes, this is just an issue which the spec leaves to implementations. (The spec is really concerned with parsing, not rendering. It's a bit awkward that we use HTML for the examples/tests, for this reason; the examples inevitably have to make decisions on rendering that go beyond what the spec demands.) |
@jgm I believe the idea of leaving that to compilers/generators/implementations is not in the spec, it would be very useful in my opinion to have that documented |
The spec doesn't say "URLs must be encoded." It just says how to recognize something as a link destination, etc. But yes, we could add a note about this. |
My that was a reference to your earlier comment (“The spec is really concerned with parsing, not rendering. It's a bit awkward that we use HTML for the examples/tests, for this reason; the examples inevitably have to make decisions on rendering that go beyond what the spec demands.”), not with this specific issue of whether to encode URLs. |
Agreed. Perhaps add a sentence or two to this paragraph:
|
Let me know what you think about the text added in the above commit. |
Sorry. I think this looks goods! 👍 |
The Commonmark spec currently results in the Japanese text in Markdown links getting converted. This is causing problems for me because I have Markdown links and HTML links on the same page, and my pa11y accessibility tests are failing with the Markdown links because they expect the Japanese text but instead are getting the converted text.
This results in the following HTML:
In this case, I do not think the text should be converted. It's perfectly valid HTML to leave the links "as is", so no additional processing should be applied.
The text was updated successfully, but these errors were encountered: