You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Markdown content is rendered on GitHub, it is rendered into the context of a webpage. This means there is already an external heading structure to contend with.
In issue and PR comments, the maximum heading level that should be used is 3 (###). In files in Code View, the maximum should be 2 (##).
I think it's debatable whether Markdown files should be written with their intended viewing location in mind - Markdown is supposed to be a rendering-agnostic markup format. But comments should probably always be written like this. So I think it would be useful to make a new rule available, but disable it by default.
I propose we make this generic, allowing the linter to customize the heading level for the situation. For example, the following configuration would be for comments on github.com:
I think this is an interesting rule to provide, and I agree it should be disabled by default. Consumers might also want to singularly import this rule even if they're not using the full accessibility set.
I might propose using the naming of start-heading-level rather than use max or min, but that's purely an ergonomic consideration.
When Markdown content is rendered on GitHub, it is rendered into the context of a webpage. This means there is already an external heading structure to contend with.
In issue and PR comments, the maximum heading level that should be used is 3 (
###
). In files in Code View, the maximum should be 2 (##
).I think it's debatable whether Markdown files should be written with their intended viewing location in mind - Markdown is supposed to be a rendering-agnostic markup format. But comments should probably always be written like this. So I think it would be useful to make a new rule available, but disable it by default.
I propose we make this generic, allowing the linter to customize the heading level for the situation. For example, the following configuration would be for comments on github.com:
Related:
The text was updated successfully, but these errors were encountered: