Repository navigation
fix(parse): render inline <br> as a line break, not literal text - #47
Merged
Merged
Conversation
`<br>` is inline raw HTML — CommonMark/GitHub render it as a hard line break — but the inline-tag branch only matched *paired* tags (`<u>`, `<ins>`, `<sub>`, `<sup>`, `<kbd>`, `<mark>`), so `<br>` fell through to a plain text leaf and the tag itself was displayed. It shows up wherever a newline cannot be written any other way, most commonly a GFM table cell produced by an AI answer (`| 4%<br>重置 18:18 |` — tables have no in-cell newline) and mid-paragraph (`第一行<br>第二行`). Parse `<br>` / `<br/>` / `<br />` (any case) into the same Plain group shape the image branch uses: a hidden MdSymbol carries the exact source text, so `toMarkdown(parseMarkdown(md))` stays byte-exact, and a Br leaf next to it renders the real `<br>`. A bare `<br>` at the start of a line now also reaches the inline parser; the HTML-block path used to claim it first (it rendered the tag as text inside a div). Verification: new `scripts/verify-inline-br` harness (28 assertions: mid-paragraph, table cell, self-closing/case spellings, nested `<u>`, leading `<br>`, autolink + code-fence regressions, byte-exact round-trip, canonical table fixed point). Existing suites unchanged: `verify-table-after-paragraph` 20/20, `verify-softbreak` 32/32; `verify-empty-blocks` 40/42 with the same two pre-existing failures as on `main`. Kernel `tsc --noEmit` clean.
|
@123soulshell is attempting to deploy a commit to the do-md's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
All contributors have signed the CLA. Thank you! |
Contributor
Author
|
I have read the CLA Document and I hereby sign the CLA |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
<br>is inline raw HTML; CommonMark and GitHub render it as a hard linebreak. The kernel's inline-HTML branch only matched paired tags (
<u>,<ins>,<sub>,<sup>,<kbd>,<mark>), so<br>fell through to aplain text leaf and the tag itself was displayed.
Repro (read-only,
@do-md/core-react0.14.0):Actual: the cell shows
4%<br>重置 11-02 18:18— the literal tag.Expected: a line break inside the cell, the way GitHub renders the same
Markdown.
This shape is common in AI output: a comparison table in a task receipt has no
in-cell newline (GFM tables cannot express one), so models write the second
line as
<br>. It also shows up mid-paragraph (第一行<br>第二行) and anywhereelse a hard break is written as inline HTML.
Fix
parseInline.ts— match bare<br>/<br/>/<br />(any case) in the<branch and build the same wrapper shape the image branch uses: a hiddenMdSymbolcarrying the exact source text, plus aBrleaf next to it thatrenders the real
<br>. The source text still lives in the model, sotoMarkdown(parseMarkdown(md))stays byte-exact.getHTMLText.ts— a bare<br>at the start of a line now falls through tothe inline parser instead of being claimed by the HTML-block path first
(which rendered the tag as text inside a
div).Attributes are intentionally out of scope —
<br class="x">keeps its currentbehavior, same as the other bare inline tags.
Verification
New harness —
cd .packages/@do-md/core && sh scripts/verify-inline-br/run.sh—28 assertions:
Brnode, and thevisible text contains no tag;
<br>,<br/>,<br />,<BR>,<Br/>all parse and round-tripbyte-exact;
<u>, leading<br>at line start, canonical-table fixedpoint;
<https://…>autolink, fenced code,<br class="x">stayliteral text.
Also ran:
verify-table-after-paragraph20/20,verify-softbreak32/32,kernel
tsc --noEmitclean.verify-empty-blocksreports 40/42 with the sametwo pre-existing failures as on
main(empty checkbox / empty blockquoteshapes, unrelated).
Rendered check in a jsdom consumer (read-only
DOMDProvider): the table cellnow contains
<br class="DOMD-Br">between the text spans, and the tag is nolonger visible.
Happy to adjust the approach (node shape, scope, or where the tag falls
through) if you'd prefer something different.