Skip to content

fix: withdraw the quote attribution, a captioned quote is a figure again - #1070

Merged
dereuromark merged 1 commit into
mainfrom
fix/withdraw-quote-attribution
Aug 15, 2026
Merged

fix: withdraw the quote attribution, a captioned quote is a figure again#1070
dereuromark merged 1 commit into
mainfrom
fix/withdraw-quote-attribution

Conversation

@dereuromark

Copy link
Copy Markdown
Contributor

What

A caption on a block quote is a figure caption again. block_quote.attribution is gone, figure.target admits a block_quote, and the spec submodule moves onto the withdrawal.

Implements markup-carve/carve#1213, which withdraws PART 9 section 4a and PART 11 section 10d.

Why the clause fell

The HTML Standard's blockquote section:

Attribution for the quotation, if any, must be placed outside the blockquote element.

and its recommended pattern, given as the way "to clearly relate a quote to its attribution (which is not part of the quote and therefore doesn't belong inside the blockquote itself)":

<figure>
 <blockquote>
  <p>The truth may be puzzling. ...</p>
 </blockquote>
 <figcaption>Carl Sagan, in "<cite>Wonder and Skepticism</cite>", ...</figcaption>
</figure>

Section 4a put the attribution inside the quote, in a <footer>, and asserted in its own text that both spellings were valid HTML.

Its model argument fails too. figure is already the generic captioned wrapper in this engine: a captioned code block is a figure whose target is the code block. What a captioned thing is called and counted as comes from the caption's own label, not from the host's node type, so a quote was never a special host.

Nothing shipped. 0.1.3 predates #1033, so this removes code no release carried, and the CHANGELOG loses those entries rather than gaining a reversal.

What comes back

> To be
^ Hamlet
<figure>
  <blockquote><p>To be</p></blockquote>
  <figcaption>Hamlet</figcaption>
</figure>

The caption numbers like any other. Measured on this branch:

{#ep}
> To be
^ Figure #: Hamlet

![x](/i.png)
^ Figure #: An image

See </#ep>.
<figure id="ep">
  <blockquote><p>To be</p></blockquote>
  <figcaption>Figure 1: Hamlet</figcaption>
</figure>
<figure>
  <img src="/i.png" alt="x">
  <figcaption>Figure 2: An image</figcaption>
</figure>
<p>See <a href="#ep">Figure 1</a>.</p>
  • block_quote.attribution is gone from the node, the AST JSON wire and the generated member sets. src/wire-fields.ts is regenerated from the moved submodule rather than hand-edited.
  • The HTML importer reads <figure><blockquote>…<figcaption> back as the figure, and a <footer> inside a quote is ordinary quoted content again.
  • The Markdown, plain-text and terminal writers lose the attribution-specific handling section 10d added (the <footer> element, the quote bar carried onto the attribution line, the removed blank line) and render a quote's caption the way they render any other figure caption.

What stays

PART 11 section 10e landed in the same commits and is untouched: a table caption still survives the Markdown target, and a code fence's title and grouping label still survive plain text and the terminal. Measured on this branch:

| H |
| --- |
| a |

Table caption

Multi-block captioned quotes also keep working. The pre-4a oracle refused them; that regression does not come back.

Downstream

carve-grammars#219 tracks the tiptap projection, which learned attribution yesterday and needs the figure projection back once this is pinnable. carve-php and carve-rs get the same revert.

markup-carve/carve#1213 withdraws PART 9 §4a and PART 11 §10d. A caption on a
block quote is not an attribution; it is a caption like any other, so a captioned
quote is a `figure` whose target is the quote - the shape this engine produced
before #1033.

WHY THE CLAUSE FELL. The HTML Standard's `blockquote` section requires that
"attribution for the quotation, if any, must be placed outside the `blockquote`
element", and gives a `<figure>` wrapping the quote with a `<figcaption>` as the
way to attach it, "which is not part of the quote and therefore doesn't belong
inside the `blockquote` itself". §4a put it inside, in a `<footer>`, and asserted
that both spellings were valid. Its model argument fails too: `figure` is already
the generic captioned wrapper, since a captioned code block is a `figure` whose
target is the code block, and what a captioned thing is called and counted as
comes from the caption's own label rather than the host's node type.

Nothing had shipped - 0.1.3 predates the port - so this removes code no release
carried, and the CHANGELOG loses those entries rather than gaining a reversal.

WHAT COMES BACK:

  `> To be` + `^ Hamlet` renders

      <figure>
        <blockquote><p>To be</p></blockquote>
        <figcaption>Hamlet</figcaption>
      </figure>

  The caption numbers like any other, so `^ Figure #: Hamlet` takes the next
  Figure from the same bucket an image uses and a numbered cross-reference to the
  quote's id resolves to "Figure 1" again.

  `block_quote.attribution` is gone from the node, from the AST JSON wire and
  from the generated member sets, and `figure.target` admits a `block_quote`.
  The spec submodule moves onto the withdrawal, and `src/wire-fields.ts` is
  regenerated from it rather than hand-edited.

  The HTML importer reads `<figure><blockquote>…<figcaption>` back as the figure,
  and a `<footer>` inside a quote is ordinary quoted content again.

  The Markdown, plain-text and terminal writers lose the attribution-specific
  handling §10d added - the `<footer>` element, the quote bar carried onto the
  attribution line, the removed blank line - and render the quote's caption the
  way they render any other figure caption.

WHAT STAYS. PART 11 §10e landed in the same commits and is untouched: a table
caption still survives the Markdown target, and a code fence's title and grouping
label still survive plain text and the terminal. Multi-block captioned quotes
also keep working; the pre-§4a code refused them in the oracle and that
regression does not come back.
@dereuromark
dereuromark marked this pull request as ready for review August 15, 2026 01:03
@dereuromark
dereuromark merged commit 16c1d94 into main Aug 15, 2026
4 checks passed
@dereuromark
dereuromark deleted the fix/withdraw-quote-attribution branch August 15, 2026 01:04
dereuromark added a commit to markup-carve/carve-grammars that referenced this pull request Aug 15, 2026
…ith it (#220)

markup-carve/carve#1213 withdraws PART 9 §4a. A caption on a block quote is not
an attribution: the engine emits a `figure` whose target is the quote again, and
`block_quote.attribution` no longer exists.

The HTML Standard's `blockquote` section requires that "attribution for the
quotation, if any, must be placed outside the `blockquote` element" and gives
`<figure>` + `<figcaption>` as the way to attach it, so the clause put the source
in the one place the standard names as wrong. Its model argument fails too:
`figure` is already the generic captioned wrapper, since a captioned code block
is a `figure` whose target is the code block.

So #218 is reverted. The projection it added - `attribution` onto a
`carveCaption` INSIDE the quote - has nothing to read, and the
`carveFigure`/`carveCaption` pair it replaced is correct again. The
`tiptap/schema-map.json` note describing where the field lands goes with it.

THE PROPERTY #218 PINNED SURVIVES ITS OWN REVERT, and that is why the test file
does not simply go away. `tests/blockquote-caption-test.js` replaces
`blockquote-attribution-test.js` with the same five documents and the same
method: mount a real editor, make an UNRELATED edit, and read what the pane would
write back. A load-only assertion cannot see this class of bug, because the
whole-document `carveSource` envelope still holds the source at load time and
only the first edit invalidates the fingerprint it is keyed to. What changed is
the shape the probe looks for - a `carveCaption` beside a `blockquote` inside a
`carveFigure`, rather than one inside the quote - and the four cases about a
caption living inside a quote, which this projection cannot produce, are gone
with the field.

The mounted ratchet moves 177 -> 173, and the four documents move back with it:
05-lists-20, 07-blockquote-with-attribution,
55-blockquote-caption-after-a-blank-line and
282-two-blank-lines-detach-a-caption-5 are render-equivalent through a mount
again. They stay in the protected list, since the failure mode is silent content
loss on the first edit rather than a visible fallback.

THE PIN IS ON AN UNMERGED BRANCH. `@markup-carve/carve` points at
carve-js `2bfa5cfe`, the head of markup-carve/carve-js#1070, because the revert
has to be pinnable before this can be measured at all. It must be re-pinned to
the merged sha before this merges.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant