Skip to content

Preserve empty lines between consecutive <br> elements - #270

Merged
eXpl0it3r merged 2 commits into
ArthurHub:masterfrom
dajiaohuang:fix/259-consecutive-line-breaks
Nov 9, 2026
Merged

eXpl0it3r merged 2 commits into
ArthurHub:masterfrom
dajiaohuang:fix/259-consecutive-line-breaks

Conversation

@dajiaohuang

Copy link
Copy Markdown
Contributor

Summary

  • Preserve an explicit newline for a <br> whose previous sibling is also a <br>, including when inline content follows the second break.
  • Add an integration regression test comparing rendered heights for one break versus two consecutive breaks.

The existing 02.Line break.htm sample contains consecutive breaks, and its checked-in baseline shows adjacent text lines without an empty line. The parser's correction only materialized a newline for a break at the start of a block or at the end before inline content; a middle consecutive break did not take that path.

Validation

  • git diff --check passed.
  • Attempted the focused integration test. The .NET 10.0.100 first-run initialized, but restore failed with NU1301 while loading https://api.nuget.org/v3/index.json (Value cannot be null. (Parameter 'path1')). No tests ran; this change is not independently validated yet.

dajiaohuang and others added 2 commits November 9, 2026 09:43
- Keep <br> in the surrounding inline run instead of splitting it into its own block
- Start the new line with the word after a line break, so a trailing <br> adds no line and a leading one does
- Ignore line breaks when summing the max-content width of a line
- Drop the newline right after a <pre>, <listing> or <textarea> start tag
- Revert the CorrectLineBreaksBlocks change, it's not needed anymore
- Update the five baselines that now show the empty lines
@eXpl0it3r
eXpl0it3r force-pushed the fix/259-consecutive-line-breaks branch from 5869bdb to a85b173 Compare November 9, 2026 09:03
@eXpl0it3r

Copy link
Copy Markdown
Collaborator

Thanks for tackling this! 🙂

The test you added was the right one, but it failed on the Windows CI jobs (the only ones running the integration tests), because the actual problem sits a bit deeper. IsInline excluded <br>, so the parser treated every <br> as a block, wrapped the text around it into separate anonymous blocks and left the <br> boxes as loose siblings at Y=0. As such, a second break never took any space, no matter how many newlines it got.

I've rebased the branch onto the current master and pushed a fix on top of your commit:

  • Treat <br> as inline, so it stays in the line it belongs to
  • End the line after a line break, instead of starting the new line with the break itself. Otherwise a trailing <br> adds an empty line and a leading one gets swallowed
  • Ignore line breaks when computing the max-content width, otherwise a table cell with Nuance<br>df gets as wide as both lines together
  • Drop the newline right after a <pre>, <listing> or <textarea> start tag, as the HTML spec says, which the old behavior had hidden so far
  • Revert the CorrectLineBreaksBlocks change, it's not needed anymore

LineBreakLayoutIntegrationTests covers the cases against what browsers render. Five baselines changed: Line break, BlockInInline, RTL, Tables and External Image. I went through each of them, and in all of them the only difference is the empty lines that were missing before.

@eXpl0it3r
eXpl0it3r merged commit ccdedc5 into ArthurHub:master Nov 9, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants