[Pipe Tables Extension] Break tables with block-level structures #386

New Issue

claunia · 2026-01-29T14:35:33Z

claunia commented

2026-01-29 14:35:33 +00:00

Originally created by @hamvocke on GitHub (Jul 31, 2020).

One more deviation from the GitHub-flavored markdown specification. Again, I'm happy to put some work into this to make markdig more compliant to the GFM specification but with this one I'm completely lost where to start (and I think the preferred behavior is not obvious either).

See this example:

The table is broken at the first empty line, or beginning of another block-level structure

With a structure like this, markdig's pipe tables behave perfectly according to the specification - rendering a table followed by a blockquote:

| abc | def |
| --- | --- |
| bar | baz |
> bar

However, this example seems to trip up markdig's pipe tables:

| abc | def |
| --- | --- |
| a | b |
c

d

According to GFM, this should result in a table with two rows in the body. The second row consists of a cell with c and another empty cell right after. d would be a new paragraph following after the table.

The pipe tables extension renders the entire table as a paragraph with the text put in verbatim, no table is generated.

I think getting a sane behavior in for this one is not that obvious. Comparing markdown parsers you can see that there's no clear consensus on how to treat this kind of case - and the GFM-specified behavior seems to be quite an outlier.

To me, the behavior shown by markdig at the moment is rather surprising. I'd have expected that at the bare minimum, I'd get a table with one body row consisting of a and b cells.

Any thoughts on how to make markdig's behavior a little more predictable or even compliant with GFM?

Originally created by @hamvocke on GitHub (Jul 31, 2020). One more deviation from the GitHub-flavored markdown specification. Again, I'm happy to put some work into this to make markdig more compliant to the GFM specification but with this one I'm completely lost where to start (and I think the preferred behavior is not obvious either). [See this example](https://github.github.com/gfm/#example-202): > The table is broken at the first empty line, or beginning of another block-level structure With a structure like this, markdig's pipe tables behave perfectly according to the specification - rendering a table followed by a blockquote: ``` | abc | def | | --- | --- | | bar | baz | > bar ``` However, this example seems to trip up markdig's pipe tables: ``` | abc | def | | --- | --- | | a | b | c d ``` According to GFM, this should result in a table with _two_ rows in the body. The second row consists of a cell with `c` and another empty cell right after. `d` would be a new paragraph following after the table. The pipe tables extension renders the entire table as a paragraph with the text put in verbatim, no table is generated. I think getting a sane behavior in for this one is not that obvious. [Comparing markdown parsers](https://babelmark.github.io/?text=%7C+abc+%7C+def+%7C%0A%7C+---+%7C+---+%7C%0A%7C+bar+%7C+baz+%7C%0Abar%0A%0Abar) you can see that there's no clear consensus on how to treat this kind of case - and the GFM-specified behavior seems to be quite an outlier. To me, the behavior shown by markdig at the moment is rather surprising. I'd have expected that at the bare minimum, I'd get a table with one body row consisting of `a` and `b` cells. Any thoughts on how to make markdig's behavior a little more predictable or even compliant with GFM?

claunia added the enhancement PR Welcome! labels 2026-01-29 14:35:33 +00:00

claunia referenced this issue

2026-01-29 14:48:05 +00:00

[PR #386] [MERGED] Emojis and smileys customization #976

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#386