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

Open
jimhester opened this Issue Jun 13, 2013 · 7 comments

Projects

None yet

7 participants

@jimhester

Input:

<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 robin850 added a commit that referenced this issue Jun 26, 2013
@robin850 robin850 Avoid escaping on HTML comments
HTML comments opening and closing tags were previously escaped. This
wasn't intended.

Fix issue #268
7f51e39
@robin850 robin850 closed this in #272 Jun 26, 2013
@robin850
Collaborator

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

@mathematicalcoffee

(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 foobar.md %}{% 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.

@konklone

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

@robin850
Collaborator

@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
@mrgordon

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.

@eonist
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 CGarces added a commit to CGarces/CGarces.github.io that referenced this issue Jan 28, 2016
@CGarces CGarces Fix the issue with Redcarped
The issue is described at vmg/redcarpet#268
7826cb8
@CGarces CGarces referenced this issue in CGarces/CGarces.github.io Jan 28, 2016
Merged

Close issue #5 #6

@joelostblom

@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