[GH-ISSUE #1263] Feature Request: Recognize `markdownlint-*` configuration comments in "non-HTML comments" (unused link reference definitions) #2499

New issue

Open

opened 2026-03-07 20:08:19 +03:00 by kerem · 1 comment

kerem commented

2026-03-07 20:08:19 +03:00

Owner

Originally created by @DianaNites on GitHub (Jun 19, 2024).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1263

HTML comments as used to configure markdownlint within a file often have the unfortunate side-effect of appearing in the final HTML source, even though unrendered.

It would be nice-to-have(TM) for the various markdownlint configuration comments to also recognize the conventional "non-HTML" comment syntax, as commonly used and supported by default in MD053.

[//]: # (markdownlint-disable MD053)
[unused]: https://example.com
[//]: # (markdownlint-enable MD053)

This would purely be a "Nice To Have(TM)" convenience feature, as it is currently possible to do this by inserting a HTML comment inside the non-HTML comment, which also does not appear in the final HTML source of most renderers, per BabelMark

[//]: # (<!-- markdownlint-disable MD053 -->)
[unused]: https://example.com
[//]: # (<!-- markdownlint-enable MD053 -->)

Another possible use-case besides convenience for this feature could be a new lint against HTML comments entirely, to make sure undesired comments don't end up user-visible without giving up on the ability to configure markdownlint inline.

It is perfectly understandable if this is not deemed worth it.

Originally created by @DianaNites on GitHub (Jun 19, 2024). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1263 HTML comments as used to configure markdownlint within a file often have the unfortunate side-effect of appearing in the final HTML source, even though unrendered. It would be nice-to-have(TM) for the various markdownlint configuration comments to also recognize the conventional "non-HTML" comment syntax, as commonly used and supported by default in MD053. ```markdown [//]: # (markdownlint-disable MD053) [unused]: https://example.com [//]: # (markdownlint-enable MD053) ``` This would purely be a "Nice To Have(TM)" convenience feature, as it is currently possible to do this by inserting a HTML comment inside the non-HTML comment, which also does not appear in the final HTML source of most renderers, per [BabelMark](https://babelmark.github.io/?text=Test%0A%0A%3C!--+Usually+visible+in+HTML+output+--%3E%0A%0A%5B%2F%2F%5D%3A+%23+(%3C!--+markdownlint+disable+MD053+--%3E)%0A%5B%2F%2F%5D%3A+%23+(This+should+not+be+in+the+HTML)%0A%0A%5B%2F%2F%5D%3A+%23+(%3C!--+Some+renderers+are+weird+--%3E)%0A%0A%5B%2F%2F%5D%3A+%23+(This+ALSO+should+not+be+in+the+HTML)) ```markdown [//]: # () [unused]: https://example.com [//]: # () ``` Another possible use-case besides convenience for this feature could be a new lint *against* HTML comments entirely, to make sure undesired comments don't end up user-visible without giving up on the ability to configure markdownlint inline. It is perfectly understandable if this is not deemed worth it.

kerem added the

enhancement

label

2026-03-07 20:08:19 +03:00

kerem commented

2026-03-07 20:08:20 +03:00

Author

Owner

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

I'm not sure how I feel about this approach, but you make a good case for it. :) That said, you also show how it's possible to accomplish the desired result today with only a few extra characters and so I am less inclined to add explicit support.

I will leave this issue open as a possible enhancement, but anyone reading this should please treat the "mixed" approach above as the current recommendation.

@DavidAnson commented on GitHub (Jun 19, 2024): I'm not sure how I feel about this approach, but you make a good case for it. :) That said, you also show how it's possible to accomplish the desired result today with only a few extra characters and so I am less inclined to add explicit support. I will leave this issue open as a possible enhancement, but anyone reading this should please treat the "mixed" approach above as the current recommendation.