# Parsing strategy for tables? **URL:** \ **Category:** Extensions\ **Created:** [February 27, 2016, 2:49pm UTC](https://talk.commonmark.org/t/parsing-strategy-for-tables/2027 "2016-02-27T14:49:57Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![xoofx](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/xoofx/32/1424_2.png) [@xoofx](https://talk.commonmark.org/u/xoofx)\ **Post date:** [February 27, 2016, 2:49pm UTC](https://talk.commonmark.org/t/parsing-strategy-for-tables/2027/1 "2016-02-27T14:49:57Z")
Hi there! I have been recently implementing the CommonMark specs for another .NET library, and while all tests are passing with latests specs (\o/ but god, never thought that Markdown parsing would be sooo difficult!), I’m tackling now the problem of implementing some extensions like tables. I have followed the parsing strategy described in CommonMark specs and it has been working well. But for tables, I’m not sure if it can fit in this strategy. If we take the principle that a table contains at least a pipe `|` we still need to analyze things like backsticks and escapes in order to avoid creating a TableBlock instead of say a ParagraphBlock. So for example, this should be correctly parsed as a table: ```auto `Column1 |` | Column2 ----------- | ------- 0 | 1 ``` but this should not: ```auto `Column1 |` Column2 0 `|` 1 ``` But now, if we follow the parsing strategy from the specs, the parsing of inlines is supposed to happen **after** the parsing of the block structure. So we would not be able to track the backsticks/escapes…etc. I have been thinking of allowing to transform the block structure (the current leaf block) while parsing the inlines if we are finding the pipe `|`. Not sure it is entirely feasible, but it seems the most obvious way. Do you have any other ideas about how to handle this? --- _[View the full topic](https://talk.commonmark.org/t/parsing-strategy-for-tables/2027)._