New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inline HTML comments are not properly ignored, and instead is treated and escaped as text. #268

jimhester opened this Issue Jun 13, 2013 · 7 comments


None yet
7 participants
Copy link

jimhester commented Jun 13, 2013


<div></div><!-- comment -->
# A Header #

Current output:

<p><div></div>&lt;!-- comment --&gt;</p>

<h1>A Header<h1>

Desired output:

<div></div><!-- comment -->

<h1>A Header<h1>

The comments are parsed correctly as long as they are on their own line, but when they are inline with other tags they are treated as text.

robin850 added a commit that referenced this issue Jun 26, 2013

Avoid escaping on HTML comments
HTML comments opening and closing tags were previously escaped. This
wasn't intended.

Fix issue #268

This comment has been minimized.

Copy link

robin850 commented Jun 26, 2013

Hey @jimhester, sorry for the delay. This issue has normally been fixed in #272. Thanks for reporting!


This comment has been minimized.

Copy link

mathematicalcoffee commented Aug 6, 2014

(Never mind --- I realised my problem must somehow be tied up with jekyll/liquid, because in a normal markdown document redcarpet treats my comments as expected, but when something about my {% capture snippet %}{% include %}{% endcapture %}{{ snippet | markdownify }} is causing the comment to be escaped. I'll pursue this with jekyll).

Quick question, this appears to have been reverted in this commit ("revert the unescaping behaviour on comments") as it "doesn't follow the conformance suite". Since it is reverted, how can I put a HTML comment into my markdown (which appears as an HTML comment in the source, rather than as &lt;!-- ... --&gt;)?

I believe that the reversion is a bug -- in Markdown HTML tags are supposed to remain as HTML tags, so an HTML comment tag <!-- ... --> in markdown should remain unescaped.


This comment has been minimized.

Copy link

konklone commented Oct 26, 2014

@robin850 Since the fix was reverted, can this ticket be re-opened, and a solution discussed?


This comment has been minimized.

Copy link

robin850 commented Oct 26, 2014

@konklone : Yes for sure ; thanks for the heads up !

For the record, I will cross-ref #415. One of the possible solution in order to be backward compatible would be to provide a callback method for comments so people can do whatever they want with this specific entity as this seems pretty common to use them to add some control or missing features.

@robin850 robin850 reopened this Oct 26, 2014


This comment has been minimized.

Copy link

mrgordon commented Apr 13, 2015

Any guidance or update on the state of this? This is a showstopper bug for me and I'll need to fix it on a fork if its too complicated for an upstream patch to be reasonable.


This comment has been minimized.

Copy link

eonist commented Jan 6, 2016

No progress on this? This is kind of a big deal since a lot of people use when creating excerpts for blog posts. Any work around other than to resort to letting Jekyll grab the first paragraph as the excerpt? To any future on-lookers: The only workaround I've found is to use kramdown with GHM, but then you don't get the code-fencing unless you serve it locally and then upload the html files to github for hosting. Then it works. But then you don't have the benefit of having github handle the serving etc.

CGarces added a commit to CGarces/ that referenced this issue Jan 28, 2016

Fix the issue with Redcarped
The issue is described at vmg/redcarpet#268

@CGarces CGarces referenced this issue Jan 28, 2016


Close issue #5 #6


This comment has been minimized.

Copy link

joelostblom commented Jun 29, 2016

@robin850 Hey, I just wanted to ask what the status is on this issue. Do you believe it is likely to be fixed, or if it is considered to be working as intended / difficult to fix since the previous fix caused the problems outlined in #304? I saw that they had this problem here as well hoedown/hoedown#115, they fixed it when switching to CommonMark, but they didn't outline any specifics regarding the inline HTML comments, at least not in that issue thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment