starred/markdig
1
0
Fork 0
mirror of https://github.com/xoofx/markdig.git synced 2026-02-04 05:44:50 +00:00
Code Issues 690 Packages Projects Releases 20 Wiki Activity

HTML comments break things #737

New Issue
Closed
opened 2026-01-29 14:44:22 +00:00 by claunia · 5 comments
claunia commented 2026-01-29 14:44:22 +00:00
Owner
Copy Link

Originally created by @alex-jitbit on GitHub (May 6, 2025).

Markdig.Markdown.ToHtml("<!--comment--> text *italic*"); //does not work, returns original
Originally created by @alex-jitbit on GitHub (May 6, 2025). ```csharp Markdig.Markdown.ToHtml("<!--comment--> text *italic*"); //does not work, returns original ```
claunia added the questioninvalid labels 2026-01-29 14:44:22 +00:00
claunia commented 2026-01-29 14:44:23 +00:00
Author
Owner
Copy Link

@xoofx commented on GitHub (May 6, 2025):

This is expected as per the specs https://spec.commonmark.org/0.31.2/#example-155

HTML requires a blank line to separate from markdown rendering, example here

If the HTML is at the beginning of a line, it is considered a HTML block, not a HTML inline.

That would be different with the following hello world <!--comment--> text *italic* here

@xoofx commented on GitHub (May 6, 2025): This is expected as per the specs https://spec.commonmark.org/0.31.2/#example-155 HTML requires a blank line to separate from markdown rendering, example [here](https://babelmark.github.io/?text=%3C!--comment--%3E+%0A%0Atext+*italic*) If the HTML is at the beginning of a line, it is considered a HTML block, not a HTML inline. That would be different with the following `hello world <!--comment--> text *italic*` [here](https://babelmark.github.io/?text=hello+world+%3C!--comment--%3E+text+*italic*)
claunia commented 2026-01-29 14:44:23 +00:00
Author
Owner
Copy Link

@alex-jitbit commented on GitHub (May 6, 2025):

Understood. I will just tell all JS-based frontend packages to produce strictly valid code, problem solved! 😂

OK, pardon my sarcasm. But your "stick to the specs or get out" approach makes the library very hard to use with UGC (user-generated content). I will have to write a pre-processor to make my code "mardig friendly" before processing.

P.S. Minutes after posting this issue I bumped into this #728 😂

@alex-jitbit commented on GitHub (May 6, 2025): Understood. I will just tell all JS-based frontend packages to produce strictly valid code, problem solved! 😂 OK, pardon my sarcasm. But your "stick to the specs or get out" approach makes the library very hard to use with UGC (user-generated content). I will have to write a pre-processor to make my code "mardig friendly" before processing. P.S. Minutes after posting this issue I bumped into this #728 😂
claunia commented 2026-01-29 14:44:24 +00:00
Author
Owner
Copy Link

@xoofx commented on GitHub (May 6, 2025):

OK, pardon my sarcasm. But your "stick to the specs or get out" approach makes the library very hard to use with UGC (user-generated content). I will have to write a pre-processor to make my code "mardig friendly" before processing.

CommonMark was created specifically to address these types of inconsistencies, which made it nearly impossible to achieve reliable rendering across different Markdown engines. Markdig adheres to the CommonMark specification to avoid ambiguity, endless debates, and subjective interpretations. If the input doesn't conform to CommonMark, it's outside the scope of what Markdig is designed to handle.

That said, I find your sarcasm a bit out of place - especially considering the significant time and effort I (and others) have dedicated over months of full-time work to provide this open-source library for free. 😒

@xoofx commented on GitHub (May 6, 2025): > OK, pardon my sarcasm. But your "stick to the specs or get out" approach makes the library very hard to use with UGC (user-generated content). I will have to write a pre-processor to make my code "mardig friendly" before processing. CommonMark was created specifically to address these types of inconsistencies, which made it nearly impossible to achieve reliable rendering across different Markdown engines. Markdig adheres to the CommonMark specification to avoid ambiguity, endless debates, and subjective interpretations. If the input doesn't conform to CommonMark, it's outside the scope of what Markdig is designed to handle. That said, I find your sarcasm a bit out of place - especially considering the significant time and effort I (and others) have dedicated over months of full-time work to provide this open-source library for free. 😒
claunia commented 2026-01-29 14:44:24 +00:00
Author
Owner
Copy Link

@alex-jitbit commented on GitHub (May 6, 2025):

CommonMark was created specifically to address these types of inconsistencies

Yes. Just like every standard ever. HTML, MIME, IMAP, etc. They all aim to "address issues", until they face the real world.

Imagine if email software was like "hey, I won't connect to Office365 mail server because MS protocol does not follow the MIME spec" (true story by the way)

especially considering the significant time and effort I (and others) have dedicated

I'm an OSS developer myself. I know how it feels.

Anyways. Thanks. Your point has been noted thank you.

@alex-jitbit commented on GitHub (May 6, 2025): > CommonMark was created specifically to address these types of inconsistencies Yes. Just like every standard ever. HTML, MIME, IMAP, etc. They all aim to "address issues", until they face the real world. Imagine if email software was like "hey, I won't connect to Office365 mail server because MS protocol does not follow the MIME spec" (true story by the way) > especially considering the significant time and effort I (and others) have dedicated I'm an OSS developer myself. I know how it feels. Anyways. Thanks. Your point has been noted thank you.
claunia commented 2026-01-29 14:44:25 +00:00
Author
Owner
Copy Link

@xoofx commented on GitHub (May 6, 2025):

Yes. Just like every standard ever. HTML, MIME, IMAP, etc. They all aim to "address issues", until they face the real world.

Oh, right, I don't live in the real world. You do. Thank you for this reminder.

Imagine if email software was like "hey, I won't connect to Office365 mail server because MS protocol does not follow the MIME spec" (true story by the way)

Oh, right, I'm not running a business, this is OSS. That explains.

I'm an OSS developer myself. I know how it feels.

Really? With that kind of comments, you just got banned from communication with me. Good luck in OSS with that kind of attitude.

@xoofx commented on GitHub (May 6, 2025): > Yes. Just like every standard ever. HTML, MIME, IMAP, etc. They all aim to "address issues", until they face the real world. Oh, right, I don't live in the real world. You do. Thank you for this reminder. > Imagine if email software was like "hey, I won't connect to Office365 mail server because MS protocol does not follow the MIME spec" (true story by the way) Oh, right, I'm not running a business, this is OSS. That explains. > I'm an OSS developer myself. I know how it feels. Really? With that kind of comments, you just got banned from communication with me. Good luck in OSS with that kind of attitude.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
extension
Hacktoberfest
invalid
PR Welcome!
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label invalid question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/markdig#737
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?