mirror of
https://github.com/xoofx/markdig.git
synced 2026-02-03 21:36:36 +00:00
Bug? Inline HTML is converted to wrong result #359
Reference in New Issue
Block a user
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 @Dixin on GitHub (Apr 18, 2020).
I work with a complicated environment, where we need to render a lot of documents with MD and HTML mixed. Some HTML
<pre>blocks are converted to wrong result.Problem
Take the following document as example:
it includes
<pre>block, which is correctly rendered as:(See: https://jsfiddle.net/dixin/0dj2b81x/)
Then I tried to process it with MarkDig:
The HTML result is messed up:
So the document becomes not readable:
(See https://jsfiddle.net/dixin/6j7yLx85/)
Partial solution
I found #348, and used its code:
Now the HTML result gets better:
The document becomes a little more readable:
(See: https://jsfiddle.net/dixin/tzkphu2m/1/)
It still has problems:
<pre>block, it removes the intentional blank line,<p>inside<pre>and outside</pre><pre>block.Questions
What should I do to render the above example document correctly?
Regarding the result HTML has wrong indent and even wrong format (
<pre>...<p>...</pre></p>), is this a bug?Thank you for help.
@MihaZupan commented on GitHub (Apr 18, 2020):
It's unfortunate every line is in a separate
preregion.The output without the
IndentedCodeBlockParserdoes seem a bit weird, I'll look into that.@Dixin commented on GitHub (Apr 20, 2020):
Thank you @MihaZupan for looking into this.
What should I do if I want to keep everything unchanged between
<pre>and</pre>?@MihaZupan commented on GitHub (Jul 11, 2020):
I haven't looked into how we would correct/change the behavior here, but it looks like it's caused by how we handle paragraph continuations.
As a workaround rn, you can add an extra line after the paragraph (note the empty line after
HTML Paragrap):This will render properly.
@Dixin commented on GitHub (Jul 12, 2020):
@MihaZupan Thank you for the reply. I have identified the problem and have a code fix. I also identified the source of this problem comes deeper from common markdown spec. Later I will file an issue for markdig and an issue for common markdown, with all details and code fix.
@MihaZupan commented on GitHub (Jul 12, 2020):
Thanks!