starred/markdownlint

Fork 0

mirror of https://github.com/DavidAnson/markdownlint.git synced 2026-04-25 09:16:02 +03:00

[GH-ISSUE #1274] MD051: Add an option to ignore case for automatically-generated heading identifiers #654

New issue

Closed

opened 2026-03-03 01:28:47 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 01:28:47 +03:00

Owner

Originally created by @Stardidi on GitHub (Jun 26, 2024).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1274

The example from the documentation reports MD051/link-fragments: Link fragments should be valid [Expected #heading-name; Actual: #Heading-Name]

# Heading Name

[Link](#Heading-Name)

I expect the behavior as described in the example. The actual logic appears to have a bug.

Originally created by @Stardidi on GitHub (Jun 26, 2024). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1274 The example from the [documentation](https://github.com/DavidAnson/markdownlint/blob/v0.34.0/doc/md051.md) reports `MD051/link-fragments: Link fragments should be valid [Expected #heading-name; Actual: #Heading-Name]` ```markdown # Heading Name [Link](#Heading-Name) ``` I expect the behavior as described in the example. The actual logic appears to have a bug.

kerem

2026-03-03 01:28:47 +03:00

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

2026-03-03 01:28:49 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 26, 2024):

The documentation you link explains why the example you show is reported as a violation:

Link fragments may be handled case-sensitively, so this rule requires fragments to exactly match the GitHub heading algorithm.

@DavidAnson commented on GitHub (Jun 26, 2024): The documentation you link explains why the example you show is reported as a violation: > Link fragments may be handled case-sensitively, so this rule requires fragments to exactly match the GitHub heading algorithm.

kerem commented

2026-03-03 01:28:49 +03:00

Author

Owner

@DerGary commented on GitHub (Aug 21, 2024):

Why is this example wrong? It exactly matches the case, so when the link anchor is treated case-sensitive than an exactly matching case should be valid and no violation! Is there a way to change the behaviour of this rule to ignore case or match case exactly??

@DerGary commented on GitHub (Aug 21, 2024): Why is this example wrong? It exactly matches the case, so when the link anchor is treated case-sensitive than an exactly matching case should be valid and no violation! Is there a way to change the behaviour of this rule to ignore case or match case exactly??

kerem commented

2026-03-03 01:28:49 +03:00

Author

Owner

@DavidAnson commented on GitHub (Aug 21, 2024):

As noted above, this rule matches the GitHub algorithm and that algorithm converts heading text to lower case. Work could be done here to allow mIxEd CaSe, but that would permit inconsistency without adding any functionality.

@DavidAnson commented on GitHub (Aug 21, 2024): As noted above, this rule matches the GitHub algorithm and that algorithm converts heading text to lower case. Work could be done here to allow mIxEd CaSe, but that would permit inconsistency without adding any functionality.

kerem commented

2026-03-03 01:28:49 +03:00

Author

Owner

@DerGary commented on GitHub (Aug 21, 2024):

I understood that it implements the GitHub algorithm but the wording in the documentation that Link fragments may be handled case-sensitively is misleading. For me this reads like this because link fragments can be handled either case sensitive or case insensitive we implemented the GitHub algorithm which handles everyting case sensitive

I will add some background why we stumbled upon this:

We write documentation in markdown and then we use mark to upload the documentation to Atlassian Confluence. Because Confluence is handling anchor links case sensitive this is a bit of a problem because we can't meet both requirements. I already added an issue to mark maybe they can transform the links on generation

@DerGary commented on GitHub (Aug 21, 2024): I understood that it implements the GitHub algorithm but the wording in the documentation that `Link fragments may be handled case-sensitively` is misleading. For me this reads like this `because link fragments can be handled either case sensitive or case insensitive we implemented the GitHub algorithm which handles everyting case sensitive` I will add some background why we stumbled upon this: We write documentation in markdown and then we use [mark](https://github.com/kovetskiy/mark) to upload the documentation to Atlassian Confluence. Because Confluence is handling anchor links case sensitive this is a bit of a problem because we can't meet both requirements. I already added an [issue](https://github.com/kovetskiy/mark/issues/492) to mark maybe they can transform the links on generation

kerem commented

2026-03-03 01:28:49 +03:00

Author

Owner

@Stardidi commented on GitHub (Aug 24, 2024):

The parsers we use are also case-sensitive, so that enhancement would help. But they also handle whitespace differently, so maybe not sufficiently...

However I had indeed read this documentation wrong, I read it as different markdown implementations handle case sensitivity differently, so we support both, this was reinforced by may of the other examples being correct markdown and this one being incorrect. Maybe some ✅ and ❌ in the docs could help accentuate when something is valid/invalid?

@Stardidi commented on GitHub (Aug 24, 2024): The parsers we use are also case-sensitive, so that enhancement would help. But they also handle whitespace differently, so maybe not sufficiently... However I had indeed read this documentation wrong, I read it as `different markdown implementations handle case sensitivity differently, so we support both`, this was reinforced by may of the other examples being _correct_ markdown and this one being _incorrect_. Maybe some ✅ and ❌ in the docs could help accentuate when something is valid/invalid?

kerem referenced this issue

2026-03-07 20:06:51 +03:00

[GH-ISSUE #654] MD022 fix in blockquote doesn't add > character #2340