Split off from #977: GFM's own pipe-table syntax cannot express colSpan/rowSpan/cell background, or a non-inlinable block (a nested table, say) inside a cell - there is no such thing in the grammar, not a gap this package's own writer chose to leave. #977 improved what genuinely could be improved within GFM syntax (an image cell now emits inline, a multi-paragraph cell joins with a real <br> line break); this issue is what's left, which needs a real HTML-table fallback rather than a small write-side patch.
A raw HTML <table> block is legal inside a GFM document (CommonMark's own "HTML blocks", condition 6 names table directly), so falling back to one when a cell needs colSpan/rowSpan/background/a nested block is a real option on the write side. But this package's raw-HTML-block handling today only ever preserves such a block as opaque, unparsed literal text (see html/html.ts's own top comment: "an html_block/html_inline node carries its literal HTML text verbatim and is never parsed as markup") - so writing an HTML table without also teaching the reader to parse one back into a real ContentTable would only improve fidelity in one direction. Read back through this same package, that HTML table would carry none of its own structure at all, which is a worse round trip than today's degraded-but-still-a-real-table pipe syntax.
A genuine fix needs:
- A real (bounded) HTML table parser: recognising
<table>/<tr>/<td>/<th> and their colspan/rowspan/style (or similar) attributes specifically, not a general HTML-to-DOM parser - this package deliberately carries no HTML-parsing dependency (html/html.ts's own top comment), so this would need to stay in that same bounded-recogniser spirit.
- A write-side decision for when to fall back to HTML at all (per cell? per table, if any cell needs it?) and how to still keep the table's own bare cells readable to a human viewing the raw markdown source.
Affected packages: markdown-codec
Split off from #977: GFM's own pipe-table syntax cannot express colSpan/rowSpan/cell background, or a non-inlinable block (a nested table, say) inside a cell - there is no such thing in the grammar, not a gap this package's own writer chose to leave. #977 improved what genuinely could be improved within GFM syntax (an image cell now emits inline, a multi-paragraph cell joins with a real
<br>line break); this issue is what's left, which needs a real HTML-table fallback rather than a small write-side patch.A raw HTML
<table>block is legal inside a GFM document (CommonMark's own "HTML blocks", condition 6 namestabledirectly), so falling back to one when a cell needs colSpan/rowSpan/background/a nested block is a real option on the write side. But this package's raw-HTML-block handling today only ever preserves such a block as opaque, unparsed literal text (see html/html.ts's own top comment: "an html_block/html_inline node carries its literal HTML text verbatim and is never parsed as markup") - so writing an HTML table without also teaching the reader to parse one back into a realContentTablewould only improve fidelity in one direction. Read back through this same package, that HTML table would carry none of its own structure at all, which is a worse round trip than today's degraded-but-still-a-real-table pipe syntax.A genuine fix needs:
<table>/<tr>/<td>/<th>and theircolspan/rowspan/style(or similar) attributes specifically, not a general HTML-to-DOM parser - this package deliberately carries no HTML-parsing dependency (html/html.ts's own top comment), so this would need to stay in that same bounded-recogniser spirit.Affected packages:
markdown-codec