@jgm:
You wrote: “Or it may occur inside an HTML comment.” — I have never thought of that one! And out of curiousity I tried it out with zhtml
:
Text here,
<!--
%%Z
vanish!
%%
-->
and text there.
And indeed, the %%Z
block inside the HTML comment gets converted to a bunch of HTML, which then vanishes inside the comment when the final HTML document is rendered! Gee!
But honestly, I won’t loose much sleep about this fancy incident: the text which zhtml
sees is the hand-written typescript created by a human author (ie: me), and why would an author (me) do something like the above?
Unless of course, one wants to comment out some Z block, a possibility that never occured to me either …
The whole thing would blow up if the converted Z block would contain two HYPHEN-MINUS characters in a row, ie “--
”, because that would destroy the HTML comment and render the final HTML document invalid.
Luckily there is no way I can think of to produce such a “--
” sequence from inside a Z Notation block
I thought that a cheap cop-out would be to require %%Z
to be preceded by an empty line: so there would be no HTML block for Markdown to preserve, but even with blank lines before %%Z
and after %%
the comment survives cmark
and makes it into the HTML document. Is that intended? A similar construct
<DIV
class="hi-there"
>
does not “survive” parsing! It gets converted into this mistake:
<DIV
<P>class="hi-there"</P>
<BLOCKQUOTE>
</BLOCKQUOTE>
which does not even resemble HTML any more. (And zhtml
didn’t touch the <DIV>
at all, using cmark -t xhtml
only gives the same result!)
Is a HTML comment treated differently than a “stretched-out” regular element like this <DIV>
? Does the CommonMark specification allow a screwed output like the one for the <DIV>
example? Why?