[GH-ISSUE #1213] HTML disable/enables comments triggered when inside Markdown inline code #640

New issue

Closed

opened 2026-03-03 01:28:41 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @rachmari on GitHub (May 15, 2024).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1213

I noticed recently that even when an HTML enable/disable comment is inside inline code (e.g., ), it is still executed.

Are Markdown inline code tags ignored by design?

For some background about why we ran into this issue, we write documentation for how to use our custom Markdownlint linter for external contributors (https://github.com/github/docs/blob/main/content/contributing/collaborating-on-github-docs/using-the-content-linter.md). That documentation uses some HTML pre tags and other things to get the Markdown to render properly, which causes other issues in our rendering pipeline.

In our docs, we'd like to write something like this in a Markdown file while also still being able to run Markdownlint on the same file:

You can use the  HTML comment `<!-- markdownlint-disable -->` to disable all rules

This will effectively disable all rules, and prevent any errors from being raised. On the opposite side, using  will enable all rules, even rules we don't include in our custom config.

Originally created by @rachmari on GitHub (May 15, 2024). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1213 I noticed recently that even when an HTML enable/disable comment is inside inline code (e.g., ``), it is still executed. I noticed that the regex `/)/gi` does not account for whether the disable/enable comments are inside inline code. If a negative lookbehind is used `/((?<!))/gi` the HTML comments are properly ignored. Are Markdown inline code tags ignored by design? For some background about why we ran into this issue, we write documentation for how to use our custom Markdownlint linter for external contributors (https://github.com/github/docs/blob/main/content/contributing/collaborating-on-github-docs/using-the-content-linter.md). That documentation uses some HTML pre tags and other things to get the Markdown to render properly, which causes other issues in our rendering pipeline. In our docs, we'd like to write something like this in a Markdown file while also still being able to run Markdownlint on the same file: ```markdown You can use the HTML comment `` to disable all rules ``` This will effectively disable all rules, and prevent any errors from being raised. On the opposite side, using `` will enable all rules, even rules we don't include in our custom config.

kerem

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

closed this issue
added the
question
label

kerem commented

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

Author

Owner

@DavidAnson commented on GitHub (May 15, 2024):

I think your lookbehind got garbled, but I'd be reluctant to "fix" this too narrowly as there is no guarantee the backticks are tight to the comment (or that nothing else is in between).

What do you think about this approach that works today: https://dlaa.me/markdownlint/#%25m%23%20Issue%201213%0A%0AText%20%60%3C!--%20markdownlint-disable%20--%3E%60%20text%0A%0A%3C!--%20markdownlint-restore%20--%3E%0A%0A%23%20Extra%20H1%0A

@DavidAnson commented on GitHub (May 15, 2024): I think your lookbehind got garbled, but I'd be reluctant to "fix" this too narrowly as there is no guarantee the backticks are tight to the comment (or that nothing else is in between). What do you think about this approach that works today: https://dlaa.me/markdownlint/#%25m%23%20Issue%201213%0A%0AText%20%60%3C!--%20markdownlint-disable%20--%3E%60%20text%0A%0A%3C!--%20markdownlint-restore%20--%3E%0A%0A%23%20Extra%20H1%0A

kerem commented

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

Author

Owner

@rachmari commented on GitHub (May 15, 2024):

@DavidAnson sorry for the typo in the issue summary. There was an extra ` (Fixed).

What do you think about this approach that works today:

I didn't know about the restore config option. Does this option restore back to the rule configuration prior to any disables/enables? I see the description in the README, but it's not clear whether it restores back to the captured configuration. It seems to imply that the restore option must be used only after the capture option is used. Is that accurate?

@rachmari commented on GitHub (May 15, 2024): @DavidAnson sorry for the typo in the issue summary. There was an extra ` (Fixed). > What do you think about this approach that works today: I didn't know about the restore config option. Does this option restore back to the rule configuration prior to any disables/enables? I see the description in the README, but it's not clear whether it restores back to the captured configuration. It seems to imply that the restore option must be used only after the capture option is used. Is that accurate?

kerem commented

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

Author

Owner

@DavidAnson commented on GitHub (May 15, 2024):

If you scroll down a bit in the README, it says there is an implicit capture at the top of every document. It's not wrong to pair every restore with a capture, but it's unnecessary if nothing has been disabled or enabled up to that point.

@DavidAnson commented on GitHub (May 15, 2024): If you scroll down a bit in the README, it says there is an implicit capture at the top of every document. It's not wrong to pair every restore with a capture, but it's unnecessary if nothing has been disabled or enabled up to that point.

kerem commented

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

Author

Owner

@rachmari commented on GitHub (May 15, 2024):

@DavidAnson thank you for the explanation. In that case, the solution you provided does work for us. Thank you! ✨

@rachmari commented on GitHub (May 15, 2024): @DavidAnson thank you for the explanation. In that case, the solution you provided does work for us. Thank you! ✨

kerem referenced this issue

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

[GH-ISSUE #640] { single-title: false; }The key isn't in quotes and there is a trailing semicolon, so that isn't valid JSON #2332