Repository navigation
fix: keep heading styles inside callouts and structured blockquotes - #3592
christianhg wants to merge 2 commits into
Conversation
`DefaultCalloutRenderer` and `DefaultBlockquoteObjectRenderer` rendered every text block in their content with its `style` forced to `normal`. The reset exists because the importer gives plain callout paragraphs the `blockquote` style, and the container already adds the `> ` prefix, so rendering that style as-is quoted the text twice. Forcing every style also dropped headings: `> [!NOTE]\n> # foo` came back as `> [!NOTE]\n> foo`, and a heading in a `types.blockquote` object lost its `#` the same way, at any nesting depth. Render container content with its own style, as at the root, except where that would lose content. `blockquote` and a missing style still render as `normal`, so custom renderers keep getting `normal` for unstyled blocks. List items keep the plain rendering, since a heading marker after a task marker reads back as text. A block holding a line feed or carriage return anywhere, in span text, a link title or image text, keeps it too: the setext rescue for multi-line headings only runs on root blocks, and a `#` heading would split the block or push part of it out of the container. Whitespace-only text keeps it so the line is dropped instead of breaking the container. A custom style now reaches the consumer's `block` renderer inside these containers, and a style with no renderer reaches `unknownBlockStyle` and is reported as a `style-fallback` degradation, as at the root. Fixes #3588
…tead of splitting it Markdown has no multi-line ATX heading. `renderBlock` wrote such a block with the default heading renderer anyway, so the line after the break read back as a paragraph of its own: a root h3-h6 with a `\n` in its text came back as two blocks, as did any heading whose rendered children gained a line break from a link title, image text or a custom mark renderer, at the root and inside containers. The setext rescue only covered a root h1/h2 whose plain text held a `\n`, and the container renderers forced such a block to `normal` without reporting the dropped style. A block whose style resolves to one of the default heading renderers now renders its children as a heading first and checks the rendered output for `\n` or `\r`. With none, it stays an ATX heading, so a custom `hardBreak` that renders no line break keeps it. With one, its output and degradation reports are exactly those of the same block stored with style `normal`, followed by a `style-fallback` with its own message. Every consumer callback gets the block as if stored with style `normal`: the `normal` renderer (or `unknownBlockStyle`, reported the same way when `normal` is missing), the `listItem` renderer of a list item, whose children keep a trailing line break as a normal item's do, and `blockSpacing` as `current` and as `next`. Degradation paths and owners still name the stored block. The paragraph render reuses the heading render when both escape the text the same way. Otherwise the children render again with paragraph escaping, and since a renderer can visit different content for different children, each render's degradations and fallbacks are buffered and only the written render's take effect, at any nesting depth. A root h1/h2 still gets a setext candidate, also when its paragraph fallback renders to '': such a block is kept through candidate verification, which runs again without it if its candidate fails, and empty-output filtering and `blockSpacing` apply to the selected outputs in their written style. Each root render, main or candidate, now collects its own degradations and fallbacks, and for each root block only those of the render that is written take effect: the main render's, or the accepted setext or blank-line candidate's. This also applies to the blank-line candidate of a normal block, which used to report the main render's losses. Degradations are reported after candidate verification, and `onLostContent` sees the same entries as `onDegradation`. The container renderers no longer special-case line breaks and go through the same rule. A custom `block` renderer for the style, a `block` function and a custom `unknownBlockStyle` are unaffected. `applyMarkdownEdit` now traces a stored heading with a line break instead of resetting every key, and restores its style from the stored value.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 3f3b54b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Bundle Stats✅ No significant changes. All scenario measurements (37)🗺️
Significant means at least 1.0 KB and 1% gzip, or at least 5 ms and 10% import time. |
portableTextToMarkdownnow renders a heading inside a callout or atypes.blockquoteobject as a heading:Other styles inside these containers now render the way they do at the root. A
blockrenderer you pass for a custom style runs there too, and a style with no renderer goes tounknownBlockStyle, which by default reports astyle-fallbacktoonDegradation. Content in theblockquotestyle, list items and whitespace-only blocks still render as plain paragraphs inside these containers.Letting headings through in containers exposed a second bug, fixed in its own commit. Markdown has no multi-line
#heading, so a heading whose rendered text holds a line break was split into a heading and a paragraph that read back as two blocks. Such a block is now written as a paragraph with its text intact, and the dropped style is reported as astyle-fallback, at any depth. Anh1orh2at the top level is still written as a setext heading where that reads back intact. A customblockrenderer for the style, or a customhardBreakthat renders no line break, keeps the heading as before.One reporting change applies to existing output. When a block is written in its setext or backslash-break form,
onDegradationand thehiddenLossesofapplyMarkdownEditnow report the losses of the form that is written, not the form it replaced. These differ only when a custom renderer reaches different content in each form.Fixes #3588