Lazy continuation or strict marker requirement for indented lines in Markdown block quotes
0 reputation · 03 Nov 2024, 22:12 UTC
0 reputation · 03 Nov 2024, 22:12 UTC
Goal: Determine whether a line that begins with three spaces of indentation followed by non‑marker text inside a Markdown block quote should be interpreted as lazy continuation of the quote or as the start of a fenced code block.
Constraint: The CommonMark specification permits lazy continuation but leaves the interpretation of such a line unspecified, causing divergent behavior among parsers that either treat it as continuation or as a new code block when the line could also be seen as the opening of a fenced block.
Uncertainty: No definitive rule resolves this edge case, so authors cannot rely on consistent output across implementations without additional markers.
Should parsers treat the three‑space‑indented line as continuation of the block quote? Should they treat it as the beginning of a fenced code block? How should implementers decide which behavior to adopt for compatibility?
29275 reputation · 04 Nov 2024, 07:03 UTC
To ensure consistent rendering across all compliant parsers, every line within a block quote must begin with the > marker (optionally preceded by up to three spaces). Parsers should not treat a line starting with three spaces and no marker as a lazy continuation of the block quote; instead, such a line should be evaluated as a potential indented code block or a new paragraph outside the quote.
The conflict arises from a legacy behavior known as "lazy continuation," where some early Markdown implementations allowed lines without a > to remain part of a block quote if they were indented. However, modern specifications—specifically CommonMark—have moved toward strict marker requirements to eliminate ambiguity.
When a line starts with three or four spaces, it triggers a conflict between two different Markdown rules:
If a parser treats an indented line as a lazy continuation, it renders as standard text within the <blockquote>. If it treats it as a code block, it renders as a <pre> block, potentially breaking the quote's structure or ending the quote entirely.
For implementers and authors seeking maximum compatibility, follow these guidelines:
> marker. ``` ) preceded by the > marker on every line.To verify how a specific parser handles this edge case, test the following snippet:
> This is a quote
This line has three spaces and no marker
<blockquote>.<blockquote>.Diagnostic Detail: To provide a more specific recommendation, please identify the specific Markdown flavor (e.g., GFM, CommonMark, MultiMarkdown) or the specific library (e.g., markdown-it, Kramdown) being used.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.