[GH-ISSUE #1618] Proposed rules for markdown comment formatting and readability. #2569

Open
opened 2026-03-07 20:08:59 +03:00 by kerem · 0 comments
Owner

Originally created by @wwarriner on GitHub (May 29, 2025).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1618

I'd like to propose one or more new rules around the use of HTML comments.

  1. No non-comment content on the same line as a comment open or close if the comment is multi-line.
  2. No comment content on the same line as a comment open or close, except for single-line comment. Could be split into open, close, both options.
  3. Exactly one space before and after comment content in single-line comments.
  4. No non-comment content on the same line as a single-line comment.

The following would trigger (1):

md <!--
comment
-->

<!--
comment
--> md

The following would trigger (2):

<!-- comment
-->

<!--
comment -->

The following would trigger (3):

<!--comment -->
<!-- comment-->
<!--  comment -->
<!-- comment  -->

The following would trigger (4):

md <!-- comment -->
<!-- comment --> md

I understand (4) may be the most contentious. The first three proposals are in line with linters, formatters, and parsers for other languages, and improve readability.

None of these should change page rendering, at least in MkDocs. All of them should be automatically fixable as well. Multiline comments would stay multiline comments, single line comments would stay single line comments, markdown content would be pushed to the appropriate locations away from the comments, and spaces in single line comments would be standardized.

I assume this would also apply to comments which are markdownlint-* directives. There is an open question of how to disable this/these rules, which might involve comments around comments. I don't think that would break anything, nor why someone would want to do that.

Originally created by @wwarriner on GitHub (May 29, 2025). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1618 <!-- Thank you for taking the time to report an issue! When deciding where to open an issue, please note there are multiple projects under the markdownlint umbrella: - https://github.com/DavidAnson/markdownlint : This is the core JavaScript/Node.js library and is used by other tools. Most issues with implementation and rule behavior belong here. - https://github.com/igorshubovych/markdownlint-cli : This is the original CLI for markdownlint. Issues specific to CLI belong here. - https://github.com/DavidAnson/markdownlint-cli2 : This is a newer CLI for markdownlint and is used by other tools. Issues specific to CLI2 belong here. - https://github.com/DavidAnson/vscode-markdownlint : This is the Visual Studio Code extension for markdownlint. Issues specific to VS Code belong here. - https://github.com/DavidAnson/markdownlint-cli2-action : This is a GitHub Action for markdownlint. Issues specific to the Action belong here. - https://github.com/markdownlint/markdownlint : This is the original markdownlint implementation for Ruby. All Ruby-related issues belong here. Before creating an issue, it's a good practice to search existing issues for something similar. If your issue has already been reported, please update the existing one with any new information. It's also good to review the documentation for any relevant details. When describing an issue, the following information is helpful: - What did you do? - What did you expect to happen? - What actually happened? - What messages or errors were there? - How can the issue be reproduced? - What version were you using? - What operating system were you using? The simplest demonstration of a problem is the most helpful. Small examples can be pasted into the issue description. (Be sure to paste as code so GitHub doesn't render the example in Markdown.) For larger examples, linking to a repository or file is more appropriate. Before proposing a new rule, please review the existing suggestions: https://github.com/DavidAnson/markdownlint/issues?q=is%3Aissue+is%3Aopen+label%3A%22new+rule%22 Thank you! --> I'd like to propose one or more new rules around the use of HTML comments. 1. No non-comment content on the same line as a comment open or close if the comment is multi-line. 2. No comment content on the same line as a comment open or close, except for single-line comment. Could be split into open, close, both options. 3. Exactly one space before and after comment content in single-line comments. 4. No non-comment content on the same line as a single-line comment. The following would trigger (1): ``` md <!-- comment --> <!-- comment --> md ``` The following would trigger (2): ``` <!-- comment --> <!-- comment --> ``` The following would trigger (3): ``` <!--comment --> <!-- comment--> <!-- comment --> <!-- comment --> ``` The following would trigger (4): ``` md <!-- comment --> <!-- comment --> md ``` I understand (4) may be the most contentious. The first three proposals are in line with linters, formatters, and parsers for other languages, and improve readability. None of these should change page rendering, at least in MkDocs. All of them should be automatically fixable as well. Multiline comments would stay multiline comments, single line comments would stay single line comments, markdown content would be pushed to the appropriate locations away from the comments, and spaces in single line comments would be standardized. I assume this would also apply to comments which are `markdownlint-*` directives. There is an open question of how to disable this/these rules, which might involve comments around comments. I don't think that would break anything, nor why someone would want to do that.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/markdownlint#2569
No description provided.