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
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?