Funny enough, you can get the desired result by inserting a line break in the <IMG> tag, like this:
<img
src="/uploads/default/original/2X/d/d2358ccd3904da10dd9f4c7af07cb2ccd88942bc.png" width="85" height="53">
<img
src="/uploads/default/original/2X/d/d2358ccd3904da10dd9f4c7af07cb2ccd88942bc.png" width="85" height="53">
This will place each <IMG> element into its own <P> element, just like in your second example. The reference implementation renders this as:
<p><img
src="/uploads/.../d2...bc.png" width="85" height="53"></p>
<p><img
src="/uploads/.../d2...bc.png" width="85" height="53"></p>
The reason for this difference in behaviour is—as far as I understand it—that in the second case the start condition number 7 in section 4.6 (“HTML blocks”) does no longer apply: The tag is split into two source lines and hence the line no longer “begins with a complete open tag or closing tag”. Thus the <IMG> element is not treated as a HTML block, but as “normal” tag inside the (inline) content of a paragraph (in this case, as it happens, the only content of that paragraph).
As an aside, note that the first output (two <IMG> elements as direct children presumably of the document’s <BODY> element) is actually invalid according to HTML rules (version 4.01; ISO 15445:2000): the <IMG> element is not one of the “block-like elements” (collected in %block;) allowed there.
However, I consider your <IMG> problem not just as a curiosity, but as an example and a symptom of the somewhat shaky way how descriptive markup (that is, start-tags, end-tags, empty-element-tags—HTML or otherwise) is processed in Markdown and CommonMark.
Conceptually, there are at least four issues/aspects to consider:
-
What gets recognized as a tag, and where?
-
How to find the end of an element which started with an explicit start-tag?
-
If a start-tag is encountered outside of a paragraph, does it start a new paragraph (will the element, alongside following inline content, be “wrapped” inside a <P> element in the output)?
-
Is the (mixed) content of an explicitly marked-up element parsed according to Markdown rules or just passed along?
In the current specification the treatment of descriptive markup depends on whether it is found inside a paragraph or outside:
-
Inside a paragraph, tags are just passed along: There is no need to find the element’s end, and content continues to be treated like regular Markdown text.
-
Outside a paragraph, tags may either start a paragraph or otherwise start, continue, or end a HTML block. Content of such an HTML block is not parsed as regular Markdown text but passed along literally.
While this approach avoids—as it IMO should—the need to actually parse the element structure (keeping track of open and/or omitted tags etc), it mixes the aspect of “content-parsing” with that of “paragraph-wrapping“.
For example, there is—as far as I can tell—no way to write in a Markdown text a “customized” paragraph with an explicit start-tag but otherwise the processing of a regular paragraph.
Consider a <NOTE> element with the same content model as an ordinary <P>—one would like to write in Markdown/CommonMark something similar to
After a regular paragraph:
<NOTE>Consider *this* example.</NOTE>
And so on.
an have it rendered as
<P>After a regular paragraph:</P>
<NOTE>Consider <EM>this</EM> example.</NOTE>
<P>And so on.</P>
I have not yet found a way to achieve this—not in CommonMark and not in (most) other Markdown variants: Either the output will have spurious <P> tags inserted, or the content will not get parsed (ignoring the Markdown-* for indicating emphasis <EM>).
Maybe it’s just me, but I really do feel that there should be an easier and cleaner way to indicate if an explicitly marked-up element should
-
get wrapped into a paragraph or not (that is, whether it is to be treated as inline or block level), and
-
have its content parsed “as usual”—that is, as Markdown-style inline text just like in a regular paragraph.
And to indicate these two aspects independently, if at all possible.
