mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-25 09:16:02 +03:00
[GH-ISSUE #113] Header vs. heading #94
Labels
No labels
bug
enhancement
enhancement
enhancement
fixed in next
fixed in next
fixed in next
new rule
new rule
new rule
pull-request
question
refactoring
refactoring
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/markdownlint#94
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @levacic on GitHub (Mar 18, 2018).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/113
This library seems to misuse the word "header" a lot, when in fact, as far as I can see, it always actually refers to a "heading". This is a common mistake all over the web (and a personal pet peeve of mine), but both the HTML standard and the CommonMark spec correctly refer to these tags as headings, whereas a header is something completely different, and even has its own HTML tag.
I realize this is because the original https://github.com/markdownlint/markdownlint library does the same, and I've created an issue there as well - markdownlint/markdownlint#194 - but that seems to be a less maintained repo, as it hasn't seen new commits in over half a year - this package seems to be more popular, especially as Node-based build systems are more common these days.
Apart from the fact that it's technically incorrect, I've also seen it cause actual confusion in practice. I'm pretty sure this change would be a BC-break, because it would require changing the naming of tags and aliases for the affected rules, but are you open to fixing the naming inconsistency at some point in the future? Furthermore, are you okay with a moving the direction of this project away from the original library by implementing a change like this?
@DavidAnson commented on GitHub (Mar 18, 2018):
Yes, I’m open to this proposal, I prefer being correct whenever possible. :) This library (now) supports multiple names for a rule, so it should be possible to add corrected names without removing the current ones. Rule description changes should not be breaking.
If you have additional guidance about what should change, please let me know - otherwise it seems that you’d suggest bulk-replacing “header” with “heading” pretty much everywhere?
@DavidAnson commented on GitHub (May 13, 2018):
Merged next branch.