🐛 FIX: html_block: blank lines inside containers prematurely terminate non-blank-line-terminator sequences

[binggao1230]

Problem

HTML blocks started with <!--, <?, <!A, <![CDATA[, or <script>/<pre>/<style>/<textarea> (CommonMark types 1–5) have specific end conditions (-->, ?>, >, ]]>, closing tags). Per CommonMark spec §4.6, these blocks continue until the matching end tag is found, or the last line of the document/container — blank lines inside them do not terminate them.

When such a block appeared inside a container (e.g. a list item), a blank line within the comment caused early termination. The scan loop in html_block checks state.sCount[nextLine] < state.blkIndent to detect container boundaries, but blank lines always have sCount = 0, so any positive blkIndent (set by the list rule) incorrectly fired the guard.

Reproduction (from #377):

from markdown_it import MarkdownIt
md = MarkdownIt()
text = '''1. item

    <!--
    The following code block specifies the full path.

    [1]: <https://example.com>
    -->
    paragraph
'''
print(md.render(text))

Before this fix, --> was escaped as --> inside a paragraph (comment prematurely closed at the blank line).

Fix

One-character addition: skip the sCount < blkIndent guard when the line is blank (state.isEmpty(nextLine)). Blank lines in sequences 6–7 (end condition ^$) still terminate correctly because an empty lineText matches ^$ through the existing end-condition check.

Test

New fixture in commonmark_extras.md covering the exact case from #377.

This pull request was prepared with the assistance of AI, under my direction and review.

[chrisjsewell]

Thanks @binggao1230, and apologies for the slow response. I agree the fix is right against the CommonMark spec: a blank line inside a list item does not end the container, so a type 1–5 HTML block should continue to its real end condition, and the reference implementation renders the #377 example as a comment.

The blocker is that this port deliberately mirrors the JavaScript markdown-it, and markdown-it 14.1.1 produces byte-identical output to markdown-it-py for this input (with html: true). The same guard, state.sCount[nextLine] < state.blkIndent, is in upstream html_block.mjs, so this is an upstream bug rather than a porting error, and it was raised there as markdown-it/markdown-it#1144. Diverging here would mean the two implementations disagree on HTML block termination, which tends to come back to us as bug reports from projects that rely on parity.

So I would rather not merge this ahead of upstream. The change is a one-liner, and your fixture translates directly, so would you be willing to open the equivalent pull request against markdown-it/markdown-it, referencing #1144? As soon as it lands there we will port it here, crediting you. I will leave this PR open in the meantime so it is not lost.