# How to move ahead with extending CommonMark **URL:** \ **Category:** Extensions\ **Created:** [November 26, 2020, 4:57am UTC](https://talk.commonmark.org/t/how-to-move-ahead-with-extending-commonmark/3706 "2020-11-26T04:57:38Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![cben](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/cben/32/407_2.png) [@cben](https://talk.commonmark.org/u/cben)\ **Post date:** [December 6, 2020, 4:56pm UTC](https://talk.commonmark.org/t/how-to-move-ahead-with-extending-commonmark/3706/9 "2020-12-06T16:56:20Z")
> [@jgm](#): > > If we go for the policy that block structure can be discerned independently of inline structure – this is embodied in the current spec – then we have to worry about how to deal with `|` characters that are not supposed to be cell separators. I think that idea currently works because all block structure is encoded at start of lines: indentation, list bullets, `>`, blank lines. Will any this be a problem for any attempt to introduce block structure in the middle of a line? Possibly silly questions: In what way do we want tables to be block structrure? Could we only consider table start/end to be block structure, and cell boundaries to be inline structure? Well, putting code spans and `\|` problem aside, it makes typographic sense to think of each cell as having a separate inline structure. For example: ```auto | table | head | |-------|------| | A*B | C*D | ``` - GFM and almost all table implementations treat these as unmatched asterisks, not markup. - a couple (maruku, s9e/TextFormatter) make _B_ and/or _D_ italic 🐛, but still treat it C as a “fresh start of independent cell”. - nobody makes _B C_ italic across cells. Good! 😌 That would make little sense as AST and would not fit HTML at all… - But mutlimarkdown and cebe/gfm have an interesting alternative: a single cell “A_B | C_D” where the inner `|` is NOT a cell separator, just regular text. Also, what about escaped \| outside backticks resulting in a single cell with textual “|”? Well, backslashes can inhibit block AND inline constructs in markdown, so it’s consistent with both positions. And it’s important to have a way to spell “|” inside a cell (other than ugly `|` or `|`) 👍. Not let’s talk code spans. I’d think that if we want: ```auto | I`J | K`L | ``` to mean a single cell with a “I`J | K`L” content, we better treat “A_B | C_D” similarly. Unfortunately, the reality is more fragmented: [https://babelmark.github.io/?text=|+table+|+head+| |-------|------| |+A\*B+++|+C\*D++| |+E\*F++\|+G\*H++| |+I`J+++|+K`L++| |+M`N++\|+O`P++|](https://babelmark.github.io/?text=%7C+table+%7C+head+%7C%0A%7C-------%7C------%7C%0A%7C+A*B+++%7C+C*D++%7C%0A%7C+E*F++%5C%7C+G*H++%7C%0A%7C+I%60J+++%7C+K%60L++%7C%0A%7C+M%60N++%5C%7C+O%60P++%7C) - github/cmark and a few others are consistent in first parsing cell boundaries, then treating A\*B and I`J as unterminated asterisk an backtick. - markdown-it and a few others do A\*B but a single cell with `J | K` code span. - maruku does the opposite! But its table support is weird in other ways, and apparently it doesn’t allow escaping | by any way — neither \ nor code span nor even \ inside code span 👎 - multimarkdown consistently treats all 4 combinations as a single cell. But nobody else does. - There is more variation about `\|` inside code span becoming `|` vs `\|` in the output 😕 I’ll post more thoughts about this soon. --- _[View the full topic](https://talk.commonmark.org/t/how-to-move-ahead-with-extending-commonmark/3706)._