You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(markdown): stop WYSIWYG hard breaks rendering as literal "<br />" (#13076)
The help/FAQ pages (e.g. /help/faq/editing) showed literal `<br />` text
because Open Library has two markdown engines that disagree on hard breaks:
* Display: OLMarkdown (vendored Python-Markdown) turns every newline into an
injected `<br/>` and has no escape syntax for hard breaks.
* Editing: the Tiptap WYSIWYG component (tiptap-markdown) serializes a hard
break as CommonMark `\` + newline.
When editor-saved content is displayed, OLMarkdown appends its `<br/>` right
after the editor's trailing `\`; the backslash escapes the `<`, so readers see
the literal text `<br />`. Every multi-line paragraph edited via the editor
accumulated this (and stray backslashes — see the page history).
Fixes both sides:
* Editor: a new OLHardBreak node serializes hard breaks as a bare newline
(OLMarkdown's dialect) instead of CommonMark `\`. Re-saving a page now also
cleans up legacy backslash/`<br>` cruft.
* Renderer: LineBreaksPreprocessor strips a lone trailing `\` before injecting
`<br/>`, so already-corrupted pages display correctly without a re-save, and
no longer glues a `<br/>` onto the line above a link-reference definition.
Adds JS round-trip tests and Python render tests; both fail without the fix.
Ref: #13074
0 commit comments