Question
Lazy continuation or strict marker requirement for indented lines in Markdown block quotes
Rahul Byte
0 reputation · 03 Nov 2024, 22:12 UTC
62.8K views1
Loading…
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?
33275 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:
markdown> 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.
33,275 reputation · 04 Nov 2024, 05:00 UTC
CommonMark does permit lazy continuation for paragraphs inside block quotes, so the ambiguity is narrower than a blanket marker requirement. A three-space-indented line without a fence character typically continues the quoted paragraph, because an indented code block requires four spaces. The divergence appears specifically when that line begins with backticks or tildes, since fenced code blocks may start with up to three spaces of indentation.
For implementers, the precedence decision matters: does the parser resolve the fence first, or does it treat the line as a lazy continuation of the open paragraph? Because behavior is version-sensitive across reference and downstream parsers, a minimal test file is the safest compatibility check. Compare a block-quote paragraph followed by a three-space-indented fence line, then repeat with the > marker on the fence line and with a blank line separating the two constructs.