Development record
The site renderer reads any block whose first line starts with three backticks as a fence, without the rule mdrecord's block walk applies: a backtick fence's info string may not contain a backtick. So a line that is a balanced code span, not a fence, is mis-rendered: '``` ```' and '```x```' render as an EMPTY command block (the value's text is lost), and '``` x ```' and '```` ``` ````' fail the whole render with an unsupported-construct error. The two block escapers that leave a balanced leading code span unescaped (termsafe.OpensBalancedCodeSpan, CommonMark-correct) inherit the defect: lifeboat's escapeLeadingMarker (introduced on this branch at 4df17e706; at f9b06e720 all four inputs rendered as paragraphs) and ideate's blockText, which has carried the same pre-existing shape since d4b825630. No injection (the info string is attribute-escaped) and no concealment of neighbouring fields. The root is mdrender's fence opener (render.go RenderBlock's first-line and per-line checks, and site compose's code-tab test) spelling its own opener instead of mdrecord's; the fix routes it through mdrecord's one opener predicate.
The site renderer reads any block whose first line starts with three backticks as a fence, without the rule mdrecord's block walk applies: a backtick fence's info string may not contain a backtick. So a line that is a balanced code span, not a fence, is mis-rendered: ' ' and 'x' render as an EMPTY command block (the value's text is lost), and 'x' and '```' fail the whole render with an unsupported-construct error. The two block escapers that leave a balanced leading code span unescaped (termsafe.OpensBalancedCodeSpan, CommonMark-correct) inherit the defect: lifeboat's escapeLeadingMarker (introduced on this branch at 4df17e706; at f9b06e720 all four inputs rendered as paragraphs) and ideate's blockText, which has carried the same pre-existing shape since d4b825630. No injection (the info string is attribute-escaped) and no concealment of neighbouring fields. The root is mdrender's fence opener (render.go RenderBlock's first-line and per-line checks, and site compose's code-tab test) spelling its own opener instead of mdrecord's; the fix routes it through mdrecord's one opener predicate.
Grounds
- pursued: the four inputs render as paragraphs carrying their text through site.Renderer, lifeboat mdBlock and ideate blockText, a real three-backtick fence still renders as a command block and a tilde fence is still refused, and a full site build is byte-identical before and after; a committed page whose rendering changed, or a line mdrecord reads as a fence that the renderer now renders as prose, would show it wrong
Frontmatter
| id | iss-2609262309556167 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609262309556167-the-site-renderer-reads-any-block-whose.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2609262322244502The site renderer's inline code span closes on the first occurrence of the opening run's text, not on a run of exactly the same length as CommonMark requires, and it trims every space from a multi-backtick span rather than one from each side. So a span opened by two backticks and holding a, three backticks, b (a CommonMark code span) is refused as an unclosed code span and fails the whole page; this record cannot quote the input literally, because the site renders every ledger record and would refuse it, and a span holding only a space renders empty. termsafe.OpensBalancedCodeSpan and mdrecord's findBacktickRun both pair runs by exact length, so a value a block escaper leaves unescaped as balanced can still be refused by the renderer: loud, not silent, and no text is published wrongly. Confirmed on a scratch copy while fixing iss-2609262309556167; the tree holds three code-span pairers (termsafe closingRun, mdrecord findBacktickRun, mdrender Inline) where one canonical primitive is wanted.