fix: drop the leading whitespace after a hard line break

[Kjubikstronk]

Marked version: 18.0.11 (53cb13f)

Markdown flavor: CommonMark

Description

CommonMark ignores leading spaces at the start of the line following a hard line break. The br rule is:

const br = /^( {2,}|\)\n(?!\s*$)/;

It consumes the break itself but not the next line's indentation, so that indentation stays on the following text token and is rendered.

Expectation

foo··
·····bar

gives <p>foo<br />\nbar</p>.

Result

<p>foo<br> bar</p>. The five spaces survive.

What was attempted

Appending * to the rule, so the break consumes the indentation that follows it.

This one is easy to measure wrongly, which is worth writing down. Neither of the comparisons normally used here can see it:

• marked's own suite compares through htmlIsEqual, which leaves ignoreWhitespaces at its default of true, so the difference is invisible and examples 636 and 637 already report as passing with no shouldFail flag.
• An exact string comparison fails both before and after the change, because marked emits <br> where the spec's reference output has <br /> followed by a newline.

Under the spec's own test/normalize.py, which normalises the self-closing slash but keeps a single space that begins a text node after a tag, the whole-spec count goes from 28 to 26. The two that move are exactly 636 and 637, and nothing else changes, in both the CommonMark and GFM runs.

Credit where it is due: I originally measured this with the two comparisons above, concluded it was not a bug, and said so in #4050. @exit0-run showed the normalize.py measurement and was right.

Contributor

• Test(s) exist to ensure functionality and minimize regression (if no tests added, list tests covering this PR); or,
• no tests required for this PR.
• If submitting new feature, it has been documented in the appropriate places.

Three tests in test/unit/marked.test.js under hard line break, covering the two-space and backslash spellings plus a soft break as a control. The first two fail without the change; the control passes either way. Full spec suite (1789) and unit suite (194) pass.

Committer

In most cases, this should be a different person than the contributor.

• CI is green (no forced merge required).
• Squash and Merge PR following conventional commit guidelines.

[vercel]

@Kjubikstronk is attempting to deploy a commit to the MarkedJS Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
marked-website	Ready	Preview	Sep 3, 2026 2:11am UTC

[UziTech]

Shouldn't there be a new line character after the <br>?

[Kjubikstronk]

marked does not emit one, and that part is not new to this PR. Its own fixtures already encode the current output:

test/specs/new/breaks.html

<p>A<br>B</p>

test/specs/new/breakline.html

<p>A<br>break line test<br>Special <code>code</code>A<br>break line test</p>

CommonMark's reference is <p>foo<br />\nbar</p>, so marked differs from it on both the self closing slash and the newline. The spec suite never flags either, because htmlIsEqual normalises both.

So the newline is a separate question from this fix, and adding it here would change breaks, breakline, and every other fixture with a <br> in it. Happy to open a separate issue if you think marked should match the reference there.

[UziTech]

We have an extension (marked-xhtml) for the self closing slash, so we don't need that in marked. I think we should add the new line after br but that can be a separate issue.

[Kjubikstronk]

Understood on both.

Dropped the self closing slash from the discussion entirely, since marked-xhtml covers it and it was only ever incidental to how I was measuring.

On the newline after <br>: agreed it should be separate, and I would rather not smuggle it in here since it would change breaks, breakline and every other fixture containing a <br>. Happy to open the issue and do the work if you want it, just say and I will file it with the fixture list.

[UziTech]

Let's add tests in test/specs/new instead of marked.test.js

[Kjubikstronk]

I tried that first and the fixture cannot fail.

I added test/specs/new/hardbreak_leading_whitespace.md with the three cases, reverted the br change, and reran. It still passes:

> hardbreak_leading_whitespace
  ok hardbreak_leading_whitespace should pass

runTests compares with htmlIsEqual, and testutils constructs @markedjs/html-differ with only ignoreSelfClosingSlash and ignoreComments set, so ignoreWhitespaces stays at its default of true. The bug here is only whitespace, <p>foo<br> bar</p> against <p>foo<br>bar</p>, so nothing under test/specs can see it, and there is no per fixture option to turn the normalisation off.

That is the same blind spot that let examples 636 and 637 report as passing all along, which is what made me call this a non bug in #4050 in the first place.

I am happy to add the fixture anyway if you want it as documentation, but it would pass whether or not the code is correct. If marked.test.js is the wrong home for the real assertions, tell me where you would like them and I will move them.

[UziTech]

You can use renderExact option like test/specs/new/whiltespace_lines.md

[Kjubikstronk]

That is the piece I was missing, and it makes what I told you wrong. Sorry, I should have grepped test/specs for an escape hatch before claiming there wasn't one.

Moved in 382f844. test/specs/new/hardbreak_leading_whitespace.md with renderExact: true, covering all six cases in one fixture: the two space and backslash spellings, a tab, a mix of spaces and tabs, and two soft break controls. The unit tests are gone from marked.test.js.

It does bite. Reverting the br change:

> hardbreak_leading_whitespace
  not ok hardbreak_leading_whitespace should pass

because renderExact goes through assert.strictEqual instead of isEqual, which is exactly the thing I said the suite could not do.

[UziTech]

Should this also remove tabs or other whitespace at the beginning of the next line?

[Kjubikstronk]

Yes, good catch. It should, and it did not. Fixed in 2342586.

The spec has no tab example in Hard line breaks, so I checked the implementations instead. Both drop tabs there, writing \t for a literal tab:

input	commonmark	markdown-it	marked before	marked after
foo··\n·····bar	<p>foo<br />\nbar</p>	same	<p>foo<br>bar</p>	<p>foo<br>bar</p>
foo··\n\tbar	<p>foo<br />\nbar</p>	same	<p>foo<br>\tbar</p>	<p>foo<br>bar</p>
foo··\n··\tbar	<p>foo<br />\nbar</p>	same	<p>foo<br>\tbar</p>	<p>foo<br>bar</p>

So the rule is now [ \t]* rather than *:

const br = /^( {2,}|\\)\n(?!\s*$)[ \t]*/;

Three unit tests added, covering a tab, a mix of spaces and tabs, and a soft break with a leading tab as a control, since that one must keep its tab and does.

Full spec suite and unit suite pass. tabs, tabs_code, list_item_tabs and blank_line_with_tabs all still pass, which was the thing I most wanted to check given #4050.

[UziTech]

Thanks! 💯