I’m sure the wording of the spec could be improved, but I think if you ponder on it long enough, eventually you will see what it means …
I’m not sure if I’m there yet, but let me try to explain how I understand it:
First of all, CommonMark is not a full HTML parser. It has a bunch of rules to take care of many common patterns, but you’ll always find some edge cases that CommonMark will “misunderstand”.
Then, there are two types of HTML blocks: Ones that look for a matching end token and therefore should yield “whole” HTML elements (those are HTML blocks 1 to 5), and the ones that just detect a “partial” HTML element (those are the kinds 6 and 7).
The latter kind doesn’t care if it gets an opening or a closing tag and it doesn’t try to match them!
So in the example above, the part starting with
<table> is a HTML block of kind 6, which will end with a blank line. It does not check for a closing
</table> tag! The next line containing
<tr> could be anything, the CommonMark parser doesn’t care if it even looks like an HTML tag, as long as it’s not a blank line. The next blank line closes the HTML block of kind 6. It doesn’t really “know” that it’s an opening “table” tag and an opening “table row” tag. It could as well be some nonsense like:
This would be the same kind 6 of HTML block. And this is the whole block. If there happens to follow a matching closing tag further down, the CommonMark parser doesn’t care.
You can check this by clicking on “AST” on this page.
No, because the
<tr> is meaningless for the parser. The blank line (in line 3) ends the HTML block consisting of
… and doesn’t care if the table or the row tag is ever closed.
And now to your original problem:
If you have a
<pre> following a line that starts with
<table, and no blank line in between, the HTML block of kind 6 “eats” your
<pre>. There will be no HTML block of kind 1, as you probably would expect. Therefore, as @kivikakk suggested, you should insert a blank line to make sure the kind 6 block is finished, in order for the block with
<pre> to properly become a kind 1 block.
The spec actually illustrates this behavior with several examples, you should have a look around example 132.