You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Test
Before text
<video width="320" height="240" controls>
<source src="movie.mp4" type="video/mp4">
Your browser does not support the video tag.
</video>
After text.
Create this wrong html output:
<h1 id="test">Test</h1>
<p>Before text</p>
<video width="320" height="240" controls>
<source src="movie.mp4" type="video/mp4">
<p>Your browser does not support the video tag. </video></p>
<p>After text.</p>
The closing </p> is wrongly placed. It shoud be before the closing </video>.
With this output, the browser never show the "After text" due to the <video> tag not closed.
The {=FORMAT} syntax turns it into a raw block which will be inserted verbatim when generating the named output format but ignored in other output formats, except Pandoc's Markdown obviously, and other "sourcey" formats which support an equivalent syntax, except again raw blocks with {=markdown} as format which will be inserted verbatim in Markdown output. It works for inlines too: Inline `<i>raw<\i>`{=html} markup.
We could conceivably add some logic that would keep track of whether an open video tag has been parsed in the inline context, and if not reject the close tag as inline. That would help with cases like this. But it's best to explicitly mark HTML as suggested above.
Assuming this sample markdown code:
Create this wrong html output:
The closing
</p>
is wrongly placed. It shoud be before the closing</video>
.With this output, the browser never show the "After text" due to the
<video>
tag not closed.Tested with:
pandoc file.md --output=file.html
Issue #8629 show the same kind of error (before correcting for
<track>
element.The text was updated successfully, but these errors were encountered: