pre & code need the same newline treatment as ul and li

[sudhirj]

There's no clear guidance on newlines in the output HTML, either on whether there should be any or where they appear.

Particularly, the <pre><code> tag in Example 1 seems to be treated like a single unit, when it isn't. The is especially clear with list examples, where <ul> and <li> aren't stuck together.

I'd suggest clarifying that leaf nodes may all have newlines after them, or that all HTML nodes do.

So Example 1 could be

<pre>
<code>foo baz     bim
</code>
</pre>

or

<pre>
<code>foo baz     bim</code>
</pre>

depending on tag content whitespace trimming, and Example 2 would be

<pre>
<code>a   a
ὐ   a
</code>
</pre>

Making these changes will help treat the code node as a child of pre and apply newlines in a consistent way. Right now the spec seems to consider pre and code as a single unit.

[cebe]

This is because <pre> preserves newlines inside of it so you can not add a newline before <code> without it becoming visible part of the code segment.

<pre><code>a
b
c
</code></pre>

renders as:

a
b
c

[cebe]

but

<pre>
<code>a
b
c
</code>
</pre>

renders as:

a
b
c

note the extra spacing because of newlines.

[sudhirj]

Hmm. You're right. Was trying to avoid giving different HTML tags their own newline treatment, but you've made the point that it needs to be done.

Would be great if the spec can have a line or two about expected newlines in the rendered markdown - since the spec checker checks the newlines as well, I think that would be beneficial. Newlines are implicitly part of the spec.

[jgm]

The spec is trying to specify parsing, leaving some details of HTML rendering unspecified. HTML is used in the examples, instead of a custom representation of an abstract syntax tree, to make it easier for people to run the tests against their own markdown processors. But eventually we'll probably change that, so that the spec examples show an AST. (A program would then be provided that would take the HTML output of your markdown processor and convert it into this AST for the comparison.)

[sudhirj]

That would be awesome. An AST would be perfect. Perhaps a JSON / YAML representation could be used to make it readable and as an interchange format - that way the use of the program would be optional.