# RFC Spec extension for \*tables\*: Syntax and transformation rules **URL:** \ **Category:** Extensions\ **Created:** [November 7, 2015, 11:42pm UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910 "2015-11-07T23:42:42Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [November 7, 2015, 11:42pm UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/1 "2015-11-07T23:42:42Z")
The following is my attempt to come up with a set of rules for _CommonMark_ tables, 1. defining the syntax of pertaining _CommonMark_ “table blocks”, and 2. describing the transformation of these blocks into a generic table model, which can be mapped into the output document type after parsing. > **EDIT 2015-11-08T13:15+01:** I have put the proposed specification extension as a “free-standing” **HTML document** [here](http://tin-pot.net/tin-pot---CommonMark_Tables_proposal_2015-11-08.html). This is the current version as of 2015-11-08, ie the same text which follows below in this posting. > > If needed, I will add and link to **updated revisions** of the spec there as well (the _Subversion_-generated time stamp right at the bottom of the document should make clear what revision you are looking at). > >           —tin-pot I think the rules are simple enough to understand and apply (at least I hope so, the wording could surely be improved a bit), as well as reasonable easy to implement, and they allow for both writing “nice” _CommonMark_ text as well as more “terse” writing styles. I think this “_CommonMark_ tables” specification could provide a fundament for an actual extension of the _CommonMark_ specification, and **comments are highly appreciated** so we can move forward to (finally) bring tables into the _CommonMark_ spec. * * * ## Table model The table specification here assumes that the table element in the target document type 1. has a distinct, but optional, “table header” element; and 2. encompasses the special case of a “degenerate” table consisting of a single cell only (ie no table header, only one row and column); and 3. allows _block content_ (paragraphs, lists, etc) inside the table data cells. This is in fact the case for the W3C HTML 4.01 `` [content model](http://www.w3.org/TR/html401/struct/tables.html#edef-TABLE): ``` ``` and for the ISO/IEC 15445:2000 HTML [`
` element type](https://www.cs.tcd.ie/misc/15445/UG.html#TABLE): ``` ``` and for the DocBook 3.1 [CALS `
`](http://www.oasis-open.org/docbook/documentation/reference/html/table.html) as well, where the table data cell is the [`` element](http://www.oasis-open.org/docbook/documentation/reference/html/entry.html) is too complex to quote here: ``` ``` and in the DocBook 5.1 [CALS table](http://docbook.org/tdg51/en/html/cals.table.html) too (but DocBook 5 also has a [HTML table](http://docbook.org/tdg51/en/html/html.table.html), compatible with XHTML). And even the `` element of the sample DTD for “general documents” in Annex E of ISO 8879:1986 could be used as a target, as each cell can contain paragraphs and lists etc: ``` ``` So there should be no problem to map our (simplistic) _CommonMark_ table into the desired target document type (the same should hold for LaTeX and RTF etc too). ## Overview A table is obviously a _container block_, bearing some similarity with _block quotes_, thus the language used here paraphrases the _block quote_ description of the _CommonMark_ specification in some places—and a natural place in the specification would be as a new sub-section 5.4, at the end of the section describing “container blocks”. The rules are intended to be general enough to allow the “abuse” of tables for things like poetry verses (see examples below): ``` | And what I really want to know is this: are things getting better or are they getting worse? ``` would (or rather: _should_) be transformed into an HTML table (for example) like this: ```
And what I really want to know is this:
are things getting better
or are they getting worse?
``` This use (or misuse?) of tables was discussed [here](http://talk.commonmark.org/t/use-escaped-space-as-nbsp/1907/18), and gave in fact the impetus for this proposal. There is obvious room for enhancement: indicating the _horizontal_ (and _vertical_?) alignment of columns (or rows, or even single cells?) is certainly useful, and _PHP Markdown Extra_ [uses colons](https://michelf.ca/projects/php-markdown/extra/#table) in “table rules” for this: ``` |:-----|:------:|------:| | left | center | right | ``` However, I feel it would be premature to include something like this here, as there are too many open questions: should we also allow a similar syntax to specify alignment of _section headings_?: ``` ##: Centered heading text :## ``` If not, why not? How would such alignment prescriptions map into target documents? What about _vertical_ aligment? A more urgent extension IMO would be a syntax to specify _column spans_ and _row spans_, ie cells which extend over multiple adjacent columns and/or rows in the output table. ## Prior art As far as I can tell, the syntax rules given here also encompass the basic _[PHP Markdown Extra](https://michelf.ca/projects/php-markdown/extra/)_ syntax for tables [implemented](https://github.com/Orc/discount) for example in the _[discount](http://www.pell.portland.or.us/~orc/Code/discount/)_ parser by [David Parsons](https://github.com/Orc) (but there is no syntax for _alignment_ and _row spans_ or _column spans_ defined in this _CommonMark_ proposal yet); but the _semantics_ are—intentionally—slightly different: This block in _PHP Markdown Extra_ ``` First Header | Second Header ------------- | ------------- Content Cell | Content Cell Content Cell | Content Cell ``` generates a table whith a `` containing the first row given; the proposed _CommonMark_ specification here would write ``` First Header | Second Header ============= | ============= Content Cell | Content Cell Content Cell | Content Cell ``` to achieve the same result. The above example using “`-`” places all rows into the `` element, which is the same element structure one gets from ``` ------------- | ------------- First Header | Second Header ------------- | ------------- Content Cell | Content Cell ------------- | ------------- Content Cell | Content Cell ------------- | ------------- ``` (only visually different—depending on the output document format and renderer) or even ``` | First Header | Second Header Content Cell | Content Cell Content Cell | Content Cell ``` * * * # Proposed specification ## 5.4 Tables The **table marker** “`|`” VERTICAL LINE U+007C is used to designate a block of lines as a **table** , and to delimit _CommonMark_ text destined for different **columns** in this table. Each **row** of the table consists of a sequence of **table data cells**. ### 5.4.1 Table block A block of lines without intervening blank lines where - the first line starts with 0 to 3 spaces of inital indent, followed by the character “`|`”; and/or - any line contains (other than white space) only “`|`”, and either zero or more “`-`” HYPHEN-MINUS U+002D, or zero or more “`=`” EQUALS SIGN U+003D; is transformed into a **table** in the output document. [OR: “… is a table” / “specifies a table” ?] A line having the second form is called a **table rule**. ### 5.4.2 Table columns Content between “`|`” in lines which are not **table rules** is split and distributed into the output table columns from left to right; the leading and the trailing “`|`” characers are optional. Leading and trailing white space between column content and the “`|`” is discarded in the output. A table may have only one column. ### 5.4.3 Table rows The _CommonMark_ text for each column is split into table data cells by introducing _row breaks_ across all columns, so that each column has the same number of cells: 1. A **table rule** introduces a row break across all columns 2. Other “row breaks” are introduced only if there are more than one column (in any one of the lines in the table block), and only if each of the plain text fragments in all columns allows it simultanously: 3. Content in table data cells emanating from multiple lines in the _CommonMark_ source will be separated by “hard line breaks” in the output table. ### 5.4.4 Examples The minimal table has only one cell: ``` |Hi! ``` Accordingly, it produces a table containing a single table data cell: ```
Hi!
``` Because the HTML `` can contain both _block_ and _inline_ elements, the `` has just character data content in this case. Single-column tables are not split into cells automatically, so this example ``` |Hello, |there! ``` would reproduce the line break, but result in only one table data cell, too: ```
Hello,
there!
``` Because line breaks are taken “literally”, and paragraph structure is preserved in single-column tables, this can be used to format for example, verses and [lyrics](https://www.youtube.com/watch?v=qfUUVLydbZM): ``` And what I really want to know is this: are things getting better or are they getting worse? | Can we start all over again? ``` Note that in this example, the line containing just the “`|`” suffices to mark this block of lines as a table: It is a _table rule line_, but lacking “`=`” or “`-`” it will _not_ introduce a new row into a single-column table. The table generated from this example has a single table data cell as well, but this time it contains _two_ paragraphs (similar to a _block quote_ containing a blank line): ```

And what I really want to know is this:
are things getting better
or are they getting worse?

Can we start all over again?

``` This could be written in a more elaborate style, but would produce the exact same result: ``` | And what I really want to know is this: | | are things getting better | | or are they getting worse? | | | | Can we start all over again? | ``` A single-column table can be broken into cells explicitly, using _table rule lines_ containing “`-`” or “`=`”: ``` | One |-- | Two | and |-- | Three ``` Now we get _three_ table body rows, each with one table data cell, but still no table header row: ```
One
Two
and
Three
``` To produce a table heading row (an `` element in HTML), one has to use a _table rule line_ with “`=`”: ``` | One |===== | Two | and |----- | Three ``` Now the first line ends up as the content of the (single-cell) table heading row: ```
One
Two
and
Three
``` Multi-column tables are usually split into cells line by line: ``` | A1 | A2 | B1 | B2 ``` which can be written somewhat terser as: ``` | A1 | A2 B1 | B2 ``` or in the equivalent syntax (using a _table rule line_): ``` ---|---- A1 | A2 B1 | B2 ``` or (nicer?) ``` A1 | A2 ---|---- B1 | B2 ``` They all produce the same element structure information: ```
A1A2
B1B2
``` Lists and blockquotes will _not_ be split into adjacent cells in different rows: for example ``` ------|----- - A1a | A2a - A1b | A2b - B1 | B2 ``` will only produce _one_ row, because the left column contains a _single_ unordered list. But the first column here ``` ------|----- - A1a | A2a - A1b | A2b B1 | B2 ``` has only a _two-item_ list, followed by a _new paragraph_: this allows a row break below `- A1b` and above `B1`, _and_ below `A2b` anyway, and we get: ```
  • A1a
  • A1b
 A2a
A2b
B1B2
``` Note that the “line break” between `A2a` and `A2b` is reproduced again using a `
` in the upper-right table data cell. Without the unordered list, we would get _three_ rows out of of the “regular” table ``` ------|----- A1a | A2a A1b | A2b B1 | B2 ``` To keep “lines” in a “paragraph” (of the content fragments in a column) together, one can indent the following lines a bit (using 0 to 3 spaces, relative to the preceding “`|`” or line start. This “joins” the first line of a paragraph with the subsequent lines together, and prohibits row breaks to be inserted: ``` ------|----- A1a | A2a A1b | A2b B1 | B2 ``` will “join” the `A1a` and `A1b` in the left column, and similarly ``` ------|----- A1a | A2a A1b | A2b B1 | B2 ``` would “join” the `A2a` and `A2b` in the right column. Both of these table blocks transform into the _exact same_ element structure: ```
A1a
A1b		 A2a
A2b
B1B2
``` Here the line breaks in _both cells in the upper row_ are reproduced, and the resulting table structure shows a close similarity to the one in the example above using an unordered list—as do the _CommonMark_ input texts for both examples. ---
**Author:** ![mofosyne](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/mofosyne/32/1438_2.png) [@mofosyne](https://talk.commonmark.org/u/mofosyne)\ **Post date:** [November 8, 2015, 3:21am UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/2 "2015-11-08T03:21:26Z")
Might you also be interested in this other thread, on a proposal for a restricted subset of pipe syntax as an alternative to CSV? [http://talk.commonmark.org/t/side-thoughts-promoting-pipe-tables-as-a-potential-alternative-to-csv-format-e-g-psv/1862](http://talk.commonmark.org/t/side-thoughts-promoting-pipe-tables-as-a-potential-alternative-to-csv-format-e-g-psv/1862) * * * Also talks about tables in [http://talk.commonmark.org/t/tables-in-pure-markdown/81/81](http://talk.commonmark.org/t/tables-in-pure-markdown/81/81) * * * An interesting approach to multi line in [http://justatheory.com/computers/markup/markdown-table-rfc.html](http://justatheory.com/computers/markup/markdown-table-rfc.html) is how PostgreSQL uses the `:` character: ( Talk in: [Madoko - microsoft research's markdown editor](http://talk.commonmark.org/t/madoko-microsoft-researchs-markdown-editor/1866/8?u=mofosyne) ) This is how PostgreSQL renders tables, with multiline cells: ```auto id | name | description | price ------+-------------+------------------------------+-------- 1 | gizmo | Takes care of the doohickies | 1.99 2 | doodad | Collects *gizmos* | 23.80 10 | dojigger | Handles: | 102.98 : : * gizmos : : : * doodads : : : * thingamobobs : 1024 | thingamabob | Self-explanatory, no? | 0.99 ``` Which might be a better and simpler way to approach this issue, than how your are suggesting at the moment. ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [November 8, 2015, 10:35am UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/3 "2015-11-08T10:35:37Z")
@mofosyne : Thanks for the helpful links! Here are some comments on the examples discussed there: * * * ### CSV table format with “pipes” > Might you also be interested in this other thread, on a proposal for a restricted subset of pipe syntax as an alternative to CSV? Nonwithstanding the question if and how colon “`:`” should and could be used in _CommonMark_ “table block”, the [“example spreadsheet”](http://talk.commonmark.org/t/side-thoughts-promoting-pipe-tables-as-a-potential-alternative-to-csv-format-e-g-psv/1862) would be recognized and parsed according to the _CommonMark_ table rules I proposed (with the exception of “`:`”, discussed later). The resulting element structure should be (_remember that I cobble together these HTML results by hand—so the usual disclaimers apply!_): ```
TablesAreCool
col 1 isleftaligned$1600
col 1 iscentered$12
col 1 isright-aligned$1
``` Note that 1. the “`:`” have been ignored here (they could obviously translate into an “appropriate” attribute in the `` elements); 2. because the “table ruler line” uses only “`-`” (and not “`=`”), the first row in the _CommonMark_ table will be placed into the _table body_, and leave the _table heading_ (the `` element of HTML) omitted (the default). If the row containing “`Tables`”, “`Are`”, and “`Cool`” **should** form a _table heading row_ (HTML `` element) in the output, the _table rule line_ could be re-written as ``` |=---------|:-------------:|------:| ``` [**NOTE** : Well, my current wording says the _table rule line_ should only contain **either** “`=`” **or** “`-`”, but that’s just a preliminary rule after all, right? 😉] But CSV has no concept of _table heading row_ anyway, IIRC … To summarize: The difference between “CSV table” and “HTML table” (or “DocBook table” etc) boils down **not to differences** in _CommonMark_ parsing or input syntax, but to differences in the generated _output_ element structure and their rendering, as far as I can tell. * * * ### Tables in pure Markdown > Also talks about tables in this [discussion](http://talk.commonmark.org/t/tables-in-pure-markdown/81/81), which has various suggestions and examples of “_CommonMark_ tables”. The [examples](http://talk.commonmark.org/t/tables-in-pure-markdown/81/80) given by @nichtich would—as far as I understand my proposal and can “simulate” a parser—all be recognized by the proposed specification (in the current wording), again with the the same two restrictions that 1. column-alignment using “`:`” is (not yet) specified; 2. to separate off a _table heading row_, a _table rule line_ must have “`=`”, because using “`-`” alone does not suffice to mark up a _table heading row_ (in the current wording). If this is deemed important, the specification could easily be adapted to cover these two details too—but I’m not sure right now _how_ the “column alignment” should be mapped into the output element structure. * * * On the other hand, your (@mofosyne’s) own [table example](http://talk.commonmark.org/t/tables-in-pure-markdown/81/78) given in the discussion over there: ``` A header | Another header | Price ==================================================== Some text here | Another bit of text | 34,10 Lorem ipsum | In principo creavit | 624,45 ---------------------------------------------------- || Total: 658,55 ``` and your comment > If there is a need to distinguish headers in tables. This could be an option, of specifying thicker lines. both reflect **exactly** my motivation for the distinction between “`=`” and “`-`” in _table rule lines_, and also **nearly exactly** matches my proposed syntax rules: Which would **require** at least one “`|`” (“pipes”, or the “official” name _vertical line_) character in _table rule lines_, because otherwise eg a block of lines containing _just one line having **only** “`=`” as content_ would be detected as a _table block_ by the syntax rules for tables: ``` A header | Another header | Price ===================|=====================|========== Some text here | Another bit of text | 34,10 Lorem ipsum | In principo creavit | 624,45 -------------------|---------------------|---------- || Total: 658,55 ``` or — !["reduced to the max"](https://cdn.commonmark.org/uploads/default/original/1X/76070c2946cf92b583deac726c8a7515b496ccfc.jpg)— this one: ``` A header | Another header | Price |= Some text here | Another bit of text | 34,10 Lorem ipsum | In principo creavit | 624,45 |- || Total: 658,55 ``` [**NOTE** : I’m not sure if one shoud **require** the “`|`” to be “free-standing” in table content lines, ie separated from cell content by white space. But I certainly think the _CommonMark_ text looks better and is easier to recognize by a human ~~parser~~ reader this way!] Any proposals for that little detail? * * * ### Open questions Questions remaining open with regard to the examples seen so far: 1. If and how should “`:`” be used and interpreted in _table rule lines_? (IMO: Sooner or later: yes; but maybe later than _right now_.) 2. Should mixing “`=`” and “`-`” in _table rule lines_ be allowed? (IMO: Yes!) 3. Is the proposed requirement to use “`=`” in a _table rule line_ if one wants to produce a _table heading row_ too simple-minded? (IMO: Probably yes, in the light of “current practice”.) 4. Should it be a requirement that “`|`” in “table content lines” (ie in lines in a _table block_ which are _not_ _“table rule lines”_) be separated from cell content by white space? (IMO: Probably yes.) Kind regards, tin-pot ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [November 8, 2015, 11:24am UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/4 "2015-11-08T11:24:35Z")
@mofosyne: Ups, I nearly forgot your last example, the “PostgreSQL” syntax for (database?) tables in “plain text”: Here we go: * * * The idea there seems to be (correct me if I’m wrong) that: 1. Each line where “`|`” is used to separate columns ends up in it’s own row; but 2. lines where “`:`” is used to separate columns are “continuation lines”, and add merely more content to the currently “open” table row. Well, regarding > Which might be a better and simpler way to approach this issue, than how your are suggesting at the moment. I would certainly agree that these rules are _simpler_ and—appropriately so for a _database plain-text dump format_—make it very clear where one table row ends and the next starts (namely at every line with “`|`”). * * * But for our (syntax use) case at hand, namely _writing_ or _authoring_ tables in a _CommonMark_ text (which is obviously a different scenario than a machine dumping a database table IMO), I’m not convinced this would help us much, and doubt this approach would be “better” in any reasonable sense: - Using “`:`” as a delimiter _in CommonMark lines containing authored content_ (ie lines that are not _table rule lines_) poses immediately the question how a “regular content” colon is supposed to be entered: one would **have** to type “`\:`” for **every** colon used in a table cell—and I expect that to occur not _that_ rarely! - Starting a new table row (or in the jargon of my proposal: introducing a _row break_ after each input line with “`|`”) would obviously **render impossible** the “abuse” (or “elegant side benefit”, depending on taste) of tables I sketched in the proposal: would certainly produce _two rows_ using the “PostgreSQL” syntax rules; and this is **not** what I would like to see here, and accordingly not what the current proposal would produce. * * * At the heart of the matter, the difference is this: - The “PostgreSQL” syntax starts new table rows “by default”, and needs explicit mark up to indicate that input lines should “continue” to add input into the same output table row. - The (proposed) _CommonMark_ syntax not only treats one-column tables slightly different than multi-column tables (for a reason), but primarily it _strives to adhere to a simple principle_, which could be paraphrased like this: > Keep _CommonMark_ input blocks (if you look at just one column of the input _table block_) **in one piece** in a single output table data cell. * * * The rules I wrote are supposed to (implicitly) substantiate this principle (and are _wrong_ if they fail to do so!). And they are a bit more complicated than one might wish for solely for one reason: an input table block like ``` A1 | A2 B1 | B2 ``` should (obvioulsy IMO, and according to “current practice” in other _Markdown_ table extensions) produce **a 2 × 2 output table** , even given that each input row content: ``` A1 B1 ``` and ``` A2 B2 ``` _is actually a single “paragraph” block_ according to _CommonMark_ syntax rules (and in fact in every _Markdown_ variant too). That’s the reason behind the—admittedly ugly, but not **too** ugly I hope— rule that allows you (or forces you, if you will) to write ``` A1 B1 ``` or ``` A2 B2 ``` in the respective input column to **make it explicit** that you want to keep _the single “paragraph” CommonMark block_ in this column together. Because of the similarity in syntax (layout) and semantics to eg an unordered list: ``` A1 - B1 ``` which also would “join” the two input lines in the respective column together into a single table data cell in the output—because of this similarity I find the “special rule” for _paragraph blocks_ inside table cells not **too** ugly, or hard to understand and apply. Seen this way, I add a third point arguing that the _PostgreSQL_ format is **not** better than the currently proposed syntax: - The _PostgreSQL_ rules would **force** you to **explicitly** mark up “continuation lines” in your input _table block_, even when the _content_ of your input table block makes it perfectly clear by itself (according mostly to existing _CommonMark_ syntax rules) that you **don’t** want a new row, by assuming that you **don’t** want _CommonMark_ blocks (like lists, blockquotes, etc) to get split and to end up in different rows of the output table. And one final point (IMO a minor minor one, and less important than the others): - No other _Markdown_ extension for tables I know of uses something like the _PostgreSQL_ syntax rules. * * * **tl;dr** The “PostgrSQL” syntax rules make perfect sense for dumping a _database table_ into an _unambiguous_ plain-text format—but not so much for _writing a table_ in a _CommonMark_ plain-text document (or _“typescript”_, if you’re like me, or whatever term you prefer). Best regards, tin-pot ---
**Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\ **Post date:** [November 8, 2015, 4:20pm UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/5 "2015-11-08T16:20:58Z")
Just some random, preliminary thoughts and observations: 1. As defined, the syntax requires too much back-tracking. 2. Leading pipe should only be optional … 3. either if the table was started (and will be ended) by a table rule 4. or after the maximum / fixed number of columns has been established unambiguously. 5. Trailing pipe can always be optional, but should be omitted if the leading one was. 6. The plus sign `+` should be an alias to pipe `|` in table rules that use the hyphen-minus `-` and the hash sign `#` should be an alias to pipe `|` in table rules that use the equals sign `=`: `+----+----+` and `#====#====#` ASCII tables in email also often employed comma `,`, period `.`, backtick `\`` and apostrophe`'`for the corners.`,----±—.`top and \``----+----'` bottom. 7. Useful table headers frequently contain multiple rows, often with cells spanning several columns. 8. There’s also table footers, which should work the inverse way to headers. Multiple table bodies (or row-groups), on the other hand, are not too common and probably don’t have to be supported, but could be with asterisk `*` or underscore `_` table rules. 9. HTML tables can cope with different number of cells in adjacent rows, but LaTeX tables (rather tabulars) are more strict and always require the right number of dividers as specified at the start. 10. Table rules can either be inspired by ATX-style headings, which support equals sign `=` and hyphen-minus `-` as used in this proposal, or by horizontal rules, which currently work with hyphen-minus `-`, asterisk `*` and underscore `_`. Only the former has an established hierarchy, `=` \> `-`. These related markups should be more coordinated, in my humble opinion. 11. One could use line breaks to separate rows in tables with a hyphen table rule separating header and body, and in tables with a header separated by an equals table rule, rows would be separated by hyphen table rules, i.e. only explicitly. This would allow row-spanning quite simply. `|----| continue cell above |----|` 12. Almost all current pipe table implementations (except Maruku) require at least one pipe in a table rule, usually it should match lines with content cells. 13. One can think of pipes constituting (parallel) columns. Rows are either established by line breaks or by the known horizontal rules. If that was true, the following should work: `|----| **** | ____ |` equals `|----|----|----|` 14. There is currently no way to specify row header cells, which are quite common. 15. Kramdown currently has the most aggressive table detection algorithm: Basically any line with a literal pipe character `|` in it constitutes a table. ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [November 8, 2015, 4:24pm UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/6 "2015-11-08T16:24:52Z")
@Crissov : Wow, that’s an impressively detailed list of remarks—grant me some time to digest it, please … ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [November 8, 2015, 7:19pm UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/7 "2015-11-08T19:19:06Z")
@Crissov : Okay, here we go (after wasting some time **again** wrestling with this site’s atrociuous _Markdown_ implementation, and on the _even more_ brain-dead “`[quote]`” mechanism …). Thank you again for the meticulous remarks, and for the mention of the - _[Maruku](http://maruku.rubyforge.org/markdown_syntax.html)_ - _[Kramdown](http://kramdown.gettalong.org/syntax.html)_ implementations of _Markdown_, which were both new to me (at least I can’t remember either one of them). I really appreciate your feedback! I’ll refer to the two syntax descriptions linked above if needed. Here are my answers to your remarks, or my remarks on your remarks on my proposal … 😉 * * * > 1. As defined, the syntax requires too much back-tracking. I’m not sure that I understand exactly what you mean by that, but I guess that you refer to the fact that a _parser implementation_ would have to do back-tracking, eg to see that this block: ``` One two three | ``` is in fact a “table block”, and not a regular _CommonMark_ paragraph (so the parser must first “see” the end of the block of lines before deciding what kind of block this is). If that’s what you mean, my first reaction would be: “So what? – The syntax is supposed to ease the _author’s_ job, not the _parser implementor’s_!” But if you have a good proposal how to remedy this situation (_for the parser_), without imposing arbitrary _restrictions on the author_ of a _CommonMark_ table, I’d be glad to discuss this issue further. [NOTE: I assume that what you _don’t mean_ is that the _human reader_ has to do “back-tracking”—which would amount to a curious way of saying “the syntax is too complicated”. Is this correct?] * * * > 2. Leading pipe should only be optional … > > 1. either if the table was started (and will be ended) by a table rule > 2. or after the maximum / fixed number of columns has been established unambiguously. I take this to mean that you _don’t want_ the line-leading “`|`” being optional in all the cases where it is now (pretty much _always_, that is). Since you can _always write_ the line-leading “`|`” character into the “table block”—on each and every line if you like—I don’t quite see the point in _disallowing_ it being omitted. Maybe it has something to do with your second remark, but you’d have to elaborate further what you mean by “establishing the maximum/fixed number of columns unambiguously”. And also: how this could be done using a (modified) table syntax. Right now I’d have to take rather wild guesses what you mean by this. * * * > 3. Trailing pipe can always be optional, but should be omitted if the leading one was. Hmm: Trailing pipe **is** always optional right now, so it can **always** be omitted if one wants to. To decide _where_ (in which specific instances) it should be omitted is thus in the hands of the _author_ of the _CommonMark_ text. Or do you rather mean: the trailing “`|`” character should not be allowed to be omitted, but instead be **required** to be there **if** there was a leading one in the same line? If so: why? What would be the advantage of this _restriction_ of the _authors choices_? Because there should be _some gain_ in introducing such a rule, IMO. * * * > 4. The plus sign `+` should be an alias to pipe `|` in table rules that use the hyphen-minus `-` and the hash sign `#` should be an alias to pipe `|` in table rules that use the equals sign `=`: > > `+----+----+` and `#====#====#` > > ASCII tables in email also often employed comma `,`, period `.`, backtick ``` and apostrophe `'` for the corners. > > `,----+----.` top and ``----+----'` bottom. This seems to be a matter of taste: while I second your suggestion that “`+`” would make for “nice” ASCII art tables, I’m not sure about “`#`”: there is no “vertical double line” after all, so both “`+`” and “`#`” are “wrong” in one direction (horizontally or vertically) in any case. I’d rather strongly oppose using “`.`” FULL STOP and “`,`” COMMA, or “`'`” APOSTROPHE to “decorate” table rule lines. And _even more so_ to suddenly change the rules of _CommonMark_ (and _all_ _Markdown_ variants) about “backtick” “```” GRAVE ACCENT. And _even still more so_ if it is for the sole reason to put a _redundant_ “backtick” where is _looks nicer_. But questions of taste aside: allowing “`.`” and a host of other characters into _table rule_ lines (just for the visual pleasure, if I understand you correctly) would not only complicate the syntax rules, and thus the parser implementation too, but would also _increase the risk_ of accidentally “recognizing” a block of _CommonMark_ lines as a “table block” (because a single “recognized” _table rule line_ alone would have this effect) which was not meant to be one. So my position is: I would probably support introducing “`+`” into _table rule_ lines, because it does in fact look “right”, and I think it is indeed a common style to write “ASCII art” tables. I would be quite sceptical regarding _additonal_ “decoration” characters beyone this one, and **strictly oppose** introducing a special exception for “backtick”, without _any_ good reason to do so nor benefit this would gain. * * * > 5. Useful table headers frequently contain multiple rows, often with cells spanning several columns. That is what I had called “col[umn] spans” in my proposal, and the vertical analogue is accordingly called “row spans”. There is no syntax I could propose for this yet, but I agree that one would be useful: as you say, “col spans” and “row spans” occur frequently in real-world tables, so this is certainly one item for a TO-DO list. * * * > 6. There’s also table footers, which should work the inverse way to headers. Multiple table bodies (or row-groups), on the other hand, are not too common and probably don’t have to be supported, but could be with asterisk `*` or underscore `_` table rules. The obvious syntax rule to “mark up” a “table footer row” in this sense would be symmetrical to the rule for _table heading rows_. I’m not sure what you mean by “multiple table bodies (or row-groups)”: there is certainly no such thing in the HTML table model—which by the way can’t represent a “table footer row” either. So in any case one would have to decide **how** exactly this should map into HTML, and also into the various other document types one would want to generate from _CommonMark_ (like _DocBook_, or _DITA_, or _LaTeX_, or ISO 12083 etc). The scant support for “table footer rows” (let alone for “multiple table bodies”) in popular document types does **not** justify this (or these) extensions, in my point of view. * * * > 7. HTML tables can cope with different number of cells in adjacent rows, but LaTeX tables (rather tabulars) are more strict and always require the right number of dividers as specified at the start. It seems that _LaTeX_ **can** do “col spans” [just fine](http://timmurphy.org/2011/11/27/spanning-columns-in-latex-tables/), using the `\multicolumn{`_n_`}` macro. (I had to look this one up too …) * * * > 8. Table rules can either be inspired by ATX-style headings, which support equals sign `=` and hyphen-minus `-` as used in this proposal, or by horizontal rules, which currently work with hyphen-minus `-`, asterisk `*` and underscore `_`. Only the former has an established hierarchy, `=` \> `-`. These related markups should be more coordinated, in my humble opinion. Nah! I don’t want to go there! – Look at the list of candidates of non-blank “characters to be used in _table rule lines_” accumulated thus far: 1. “`|`” VERTICAL LINE: We probably all agree about that one. 2. “`-`” HYPHEN-MINUS: And about that one too. 3. “`=`” EQUALS SIGN: In my proposal, but I’m not so sure any more. 4. “`+`” PLUS SIGN: Probably okay, just for the looks of it. 5. “`:`” COLON: Will likely be used to signify horizontal alignment. 6. “`#`” NUMBER SIGN: I see no point in this one. 7. “`.`” FULL STOP: Or in this one. 8. “`,`” COMMA: Or in this one. 9. “`'`” APOSTROPHE: Or in this one, either. 10. “```” GRAVE ACCENT: You know what I think about **this one** … 11. “`*`” ASTERISK: Why, what should that buy us? 12. “`_`” LOW LINE: Is redundant too (and _vertically asymmetric_ without reason or meaning). I can hardly come up with _three_ different kinds of _table rule lines_ (using SPACE alone, or HYPHEN-MINUS, or EQUALS SIGN), and reasons to have them! The COLON is so much entrenched in “prior art” (for horizontal alignment of columns rsp cells) that it seems unavoidable: I think of it as a “reserved” character in this sense. As I said, I’m kind-of indifferent about PLUS SIGN, at it looks like an innocuous addition with some aesthetic value as well as existing practice (in “ASCII art” tables, I don’t know and care less about _Markdown_). But all the other seven (or eight, or even **nine**!) needless characters? No. * * * > 9. One could use line breaks to separate rows in tables with a hyphen table rule separating header and body, and in tables with a header separated by an equals table rule, rows would be separated by hyphen table rules, i.e. only explicitly. This would allow row-spanning quite simply. > > ``` > |----| continue cell above |----| > > ``` I have a difficult time trying to understand this remark: - On can not use line breaks (in the sense of blank lines) in _table block_; on the other hand there is obviously a line break after each line in the block: so which line breaks do you mean? - On using a _table rule line with HYPHEN-MINUS in it_ to separate a _table header row_ from the first _table body row_: yes, that’s already there (well, using EQUALS SIGN, but that’s a trivial change). - If I understand you correctly, you propose that a HYPHEN-MINUS _table rule line_ would **not** produce a _table heading row_ **if** (all? one? any?) other _table rule line_ in the block _also_ uses HYPHEN-MINUS—correct? But if I understand you mentioning “row-spanning” right: the example _table rule line_ you give is supposed to be used like this? : ``` | A1 | A2 | A3 | |----| continue cell above |----| | b1 | b21 | b22 | b3 | ``` (With some different “decoration” in place of the “`continue cell above`” text, obviously.) This is certainly an interesting idea for marking up “col spans”! How about _actually using_ the PLUS SIGN for something meaningful: ``` | A1 | A2 | A3 | |----|----------+----------|----| | b1 | b21 | b22 | b3 | ``` A parser could “see” by the VERTICAL LINEs in the first row that there are _three_ cells to fill in the **current** row, and by the VERTICAL LINEs together with the PLUS SIGN(s) in the _table rule line_ below this first row, that the _second_ cell actually spans across _two_ cells (the second and the third) in the **next** row. **Nice!** _I think we’re on our way towards a “col span” syntax!_ * * * > 10. Almost all current pipe table implementations (except _Maruku_) require at least one pipe in a table rule, usually it should match lines with content cells. As far as I can tell, _[Maruku](http://maruku.rubyforge.org/markdown_syntax.html)_ uses the _[PHP Extra syntax](https://michelf.ca/projects/php-markdown/extra/#table)_ for tables, and I think this requires at least one “`|`” in each line of the “table block”. Note that the current wording of my proposal _intends_ to require at least one “`|`” in each _table rule line_—if my text can be interpreted otherwise, I’d have to check and change that. * * * > 11. One can think of pipes constituting (parallel) columns. Rows are either established by line breaks or by the known horizontal rules. If that was true, the following should work: > > `|----| **** | ____ |` equals `|----|----|----|` Yes, so far I was under the impression that there is no difference in _meaning_ associated with the suggested plethora of “table rule characters”, so your two _table rule lines_ would actually have the exact same “meaning” (ie be translated in the exact same way), as would the variations: ``` |====|*--*|--__| |....|''''|,,,,| |----| **** | ____ | |----# **** | ____ # #----| **** # ____ ` '----| **** | ____ | |` `-|*--*|--__| ``` You see why I would find this bizzare? * * * > 12. There is currently no way to specify row header cells, which are quite common. No, there is: the wording of the current proposal implies that a _table rule line_ with (at least one) EQUALS SIGN in it can be used for this purpose—but this is probably too restrictive. I expect that I will change that soon, so that a any “non-blank” _table rule line_ with HYPHEN-MINUS and/or EQUALS SIGN in it will produce (ie split off) a _table heading row_. (Provided this _table rule line_ is placed below the first _content row line_ in the block, of course!) Or did you mean something else by “specify row header cells”? * * * > 13. _Kramdown_ currently has the most aggressive table detection algorithm: Basically any line with a literal pipe character | in it constitutes a table. I glanced through the _[Kramdown](http://kramdown.gettalong.org/syntax.html)_ syntax description and didn’t find anything particularly “aggressive” or disturbing, or even surprising: as far as I can see, the table syntax there pretty much is equivalent to my proposed syntax, where “any line with a literal “`|`” in it” (and only white space else) **is** a _table rule line_, and **does** constitute a “table block”. So far, I fail to see a problem with this rule. * * * **tl;dr** : 1. A syntax for “column spans” is needed (and for “row spans” probably too). 2. The PLUS SIGN could be used in such a syntax. 3. The current proposal’s wording requires a _table rule line_ containing (at least one) EQUALS SIGN “`=`” to split off and produce a _table heading row_: this is too restrictive and will be changed. 4. The COLON “`:`” will sooner or later be used to indicate _horizontal alignment_ of table columns (or cells), adopting the use of COLON in existing _Markdown_ table syntaxes. 5. So far I can see no grave incompatibilities between my proposal and popular _Markdown_ syntaxes. 6. I find these two “meta-principles” important, will try to adhere to them, and will oppose throwing them out for no good reason (because IMO they distinguish the _CommonMark_ and generally the _Markdown_ approach from all the other “plain-text” syntaxes out there): - Syntax rules should suit _the author_ (of _CommonMark_ texts, not of the syntax rules, of course!), and not _the parser_ (implementation and implementor). - Good syntax rules are (a) **few** in number, (b) **easy** to understand, and (c) **flexible** to apply. But an explicit discussion about these “principles” and what they imply would be better suited for a separate item in the `talk.commonmark` list of topics. Kind regards, tin-pot ---
**Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\ **Post date:** [November 8, 2015, 10:05pm UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/8 "2015-11-08T22:05:11Z")
1. Back-tracking is hard for both, human and computer parsers. The type of block should be determined within the first two lines. 2. Making leading pipe mandatory in most cases is a direct consequence of issue 1. 3. Trailing pipe is similar to trailing hash signs in headings. I just wanted to make clear that although the reasoning is different, they should still parallel leading pipes. 4. I’m not a big fan of hash-equals, but it is commonly used in adhoc email tables, which was the major source for original Markdown. The note on corner symbols was rather informative, not a proposal to include them. 5. Your proposal makes multi-row headers impossible. That’s bad. 6. HTML does support multiple `` elements per table, and the `scope` attribute for headers has a `rowgroup` value. Latex’s `longtable` even allows multiple headers and footers, i.e. one on each page for tables spanning multiple pages. 7. I meant that in HTML you can have 3 explicit `` in one row, 2 in the one before and 4 in the one after, but in LaTeX when you specify 3 columns you need to have 2 ampersands `&` and a line end `\\`. That’s just something to consider when deciding whether each line of a table must have the same number of pipes `|`. 8. My point was , you’re using the heading characters `=` and `-`, but “rule” (as in `
`) terminology. I’ve already raised the topic of harmonization in a [thread of its own](http://talk.commonmark.org/t/harmonizing-headings-horizontal-rules-tables-and-even-bullet-lists/1876). It’s mostly a matter of consistency. 9. This follows from issues 8 and 11. I’ll explain it further down. Your plus sign `+` for `colspan` idea seems worthwhile to explore further. 10. See [this example](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%7C+th+%7C+th+%7C%0A-----------%0A%7C+td+%7C+td+%7C%0A) for what I meant, I’m not sure why Maruku sees just one column, though. When I started to write my unfinished CM table syntax proposal, I tried to reuse horizontal rules, thinking that existing implementations already supported that. 11. No, you’re creating a straw man: comma, period, apostrophe, backtick and even hash sign are completely don’t apply here at all. ` **** ` and ` ____ ` are equivalent to `----` in generating horizontal rules outside “column blocks”. Normal CM text is written in an implicit 1-column block. Pipes would constitute explicit column blocks. An explicit 1-column block could be treated in a special way (like Pandoc does). I was arguing that the result of “horizontal rules” would be slightly different in explicit column blocks, i.e. `` instead of `
` in HTML. 12. Row header cell in HTML: `…row headernormal content` 13. Try [`foo | bar`](http://johnmacfarlane.net/babelmark2/?normalize=1&text=foo+%7C+bar) 14. Syntax for a caption (i.e. table heading) is missing. (I forgot to mention that before.) ## Code examples for 2. (optional leading pipe) Table started and ended with table rule: ``` ---|--- A | B ---|--- ``` Table with unambiguous number of columns from first row: ``` | A | B C | D ``` ## Code examples for 9. (possible different handling of `=` and `-` table rules) The HTML output below only shows the contents of the ``, the header is always the same: ```
A B
``` > ``` | A | B | |---|---| | C | D | | E | F | C D E F ``` [Test implementations](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%7C+A+%7C+B+%7C%0A%7C---%7C---%7C%0A%7C+C+%7C+D+%7C%0A%7C+E+%7C+F+%7C%0A) > ``` | A | B | |===|===| | C | D | | E | F | C E D F ``` or maybe ``` C
E D
F ``` [Test implementations](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%7C+A+%7C+B+%7C%0A%7C%3D%3D%3D%7C%3D%3D%3D%7C%0A%7C+C+%7C+D+%7C%0A%7C+E+%7C+F+%7C%0A) > ``` | A | B | |===|===| | C | D | |---|---| | G | H | C D G H ``` [Test implementations](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%7C+A+%7C+B+%7C%0A%7C%3D%3D%3D%7C%3D%3D%3D%7C%0A%7C+C+%7C+D+%7C%0A%7C---%7C---%7C%0A%7C+G+%7C+H+%7C%0A) > ``` | A | B | |===|===| | C | D | |---| F | | G | H | C D F H G ``` or maybe ``` C D
F
H G ``` [Test implementations](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%7C+A+%7C+B+%7C%0A%7C%3D%3D%3D%7C%3D%3D%3D%7C%0A%7C+C+%7C+D+%7C%0A%7C---%7C+F+%7C%0A%7C+G+%7C+H+%7C%0A) ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [November 8, 2015, 11:54pm UTC](https://talk.commonmark.org/t/rfc-spec-extension-for-tables-syntax-and-transformation-rules/1910/9 "2015-11-08T23:54:31Z")
> 1. Back-tracking is hard for both, human and computer parsers. The type of block should be determined within the first two lines. If this should be a problem, I would agree to a simple rule like - There _must_ be a line containing a “`|`” character (ie either a _table rule line_ or an explicit _table content line_) within the first _N_ lines of a “table block” for the block to be recognized as a table. Would that reduce back-tracking enough in your opinion (you seem to prefer _N_ = 2 in this rule)? * * * There is nothing I have to add to (2.), (3.), and (4.) for now. * * * > 5. Your proposal makes multi-row headers impossible. That’s bad. I have to admit that I didn’t aim at making _every_ table structure possible in (say) HTML expressible in the _CommonMark_ table syntax. However, since we already have _three_ different kinds of _table rule lines_, it should be possible to come up with rules for them to “split off” multiple input rows for an output _table header row_ (and for a _table footer row_ too). I will cook up some syntax for it, if you don’t already have an idea. * * * > 6. HTML does support multiple `` elements per table, and the scope attribute for headers has a rowgroup value. Latex’s longtable even allows multiple headers and footers, i.e. one on each page for tables spanning multiple pages. The same answer as to (5.) applies here in a way: I’m not sure it is worthwile to reflect every feature an HTML table exhibits in the _CommonMark_ syntax. There are already a lot of HTML elements and constructions without a _CommonMark_ syntax, and this will probably not change either (think of the “logical character styles” like ``, or the group of `
` related element types). I’d rather have a basic table syntax soon (with an implementation to gain practical experience using that syntax) than accumulating syntax for rarely used table constructs (I for once have never used multiple table heading rows, or multiple table bodies, or even a single table footer row). As long as we don’t preclude now that later on syntax extensions to cover more of these features can be added (for example, by nailing down the same meaning for too many syntax variants), I think this is the right approach. * * * > 7. I meant that in HTML you can have 3 explicit `` in one row, 2 in the one before and 4 in the one after, but in LaTeX when you specify 3 columns you need to have 2 ampersands `&` and a line end `\\`. That’s just something to consider when deciding whether each line of a table must have the same number of pipes | Hmm: so far there is no requirement that each line has the same number of “`|`”, but that alone doesn’t help—one has to have a means to “distribute” the “`|`” to the right “places” (so that they align with the rows above and below) so to say. An ad-hoc syntax resolving this would be to treat either - adjacent “`|`” characters in a special way, or - use decimal numbers adjacent to the “`|`” characters in order to let something like ``` | a | | c | ``` mean "three cells with “`a`”, “” (nothing), and “`c`” in it, while ``` | a || c | | a 2| c | ``` would both mean “a 2-column wide cell with “`a`” in it, and a one-column wide “regular” cell with “`c`” in it”. Wheras ``` | a | c || | a | c 2| ``` would have the two-column wide (2-col-span) cell on the right, containing “`c`”. The syntax using digits (or numbers) is clearly a bit ugly. And I would prefer the style using PLUS SIGN in a _table rule line_ over both of these ad-hoc ideas. * * * > 8. My point was, you’re using the heading characters `=` and `-`, but “rule” (as in `
`) terminology. I’ve already raised the topic of harmonization in a thread of its own. It’s mostly a matter of consistency. I hadn’t made the connection with “horizontal rules” in my mind like this. For example, you can (often, at least in older books) [see](https://en.wikipedia.org/wiki/Section_%28typography%29#/media/File:Section_break_01_by_Pengo.jpg) a row of spaced-out asterisks or more ornate “[asterisms](https://en.wikipedia.org/wiki/Asterism_%28typography%29)” and “[fleurons](https://en.wikipedia.org/wiki/Fleuron_%28typography%29)” as a _separator_ (just like a horizontal rule) between parts of (for example) the same chapter. Wikipedia has more on this under “[section (typography)](https://en.wikipedia.org/wiki/Section_%28typography%29)”. I associate _this_ with the use of “`*`” in _CommonMark_ horizontal rules, and I see no such connection from asterisks to “horizontal rules” (or are these called “leaders”?) between table rows; therefor—at least for “`*`”—I see no inconsistency either. [EDIT: Oh wait—the _terminology_ is the problem? How do you call the thin, black, straight, horizontal and vertical lines across a table, between rows and columns and thus cells? “Rules”, “borders”, “lines”, “contours”? I’m not too fond of the term “table rule lines” either … I’d like to emphasize that the use of “`|`”, “`-`”, “`=`”, and “`+`” too has nothing to do with _CommonMark_ syntax for “section headings” or “horizontal rules”: people have been using these characters for ASCII box drawing (of tables, of underlined headings, and so on) probably long before John Gruber’s first day in school. ] * * * > 9. […] Your plus sign + for colspan idea seems worthwhile to explore further. Yes, I think (or hope) so too. * * * > 10. […] When I started to write my unfinished CM table syntax proposal, I tried to reuse horizontal rules, thinking that existing implementations already supported that. I think this example (using a “`-`”-only line to separate rows) looks kind of weird: I wouldn’t format an “ASCII art” table like that, because the horizontal rule “cuts” the table into two pieces in a very visually “dominant” way. Are there any reasons why this format should be supported? * * * > 11. No, you’re creating a straw man: comma, period, apostrophe, backtick and even hash sign are completely don’t apply here at all. \*\*\*\* and \_\_\_\_ are equivalent to ---- in generating horizontal rules outside “column blocks”. As I said, I don’t follow your transferring of the “horizontal rule” syntax variations to the _table rule line_ syntax. In short: why would one _want_ to use asterisks “`*`” between two table rules? Or low lines “`_`”? They would have the same meaning anyway, right? IMO the variety offered for the current _CommonMark_ horizontal rules is a direct reflection of the typographical variety used in “section breaks”, as discussed above; and it _doesn’t_ apply to the graphical means to make the border between table cells visible. * * * > 11. [cont.] Normal CM text is written in an implicit 1-column block. Pipes would constitute explicit column blocks. An explicit 1-column block could be treated in a special way (like Pandoc does). I was arguing that the result of “horizontal rules” would be slightly different in explicit column blocks, i.e. instead of > > * * * > in HTML. You mean “why can’t I write a horizontal rule in a 1-column block (aka “degenerate table” like I can eg in a block quote”? Like this in a block quote: ``` > Para para para. Stand by for a short break: > > * * * > > And we're in the next para. ``` I could be wrong, but wouldn’t the current “table syntax” shebang imply that _the same_ happens for this: ``` | Para para para. Stand by for a short break: | | * * * | | And we're in the next para. ``` At least I’m with you that this _should_ transform into - a paragraph, - a horizontal rule, - another paragraph nested into a table (one cell, or three cells) or even not in a table at all. But it is _important_ that the same _line breaking_ rules apply as for a table: the two paragraphs in the “table” example would receive “hard line breaks” in the output (reflecting the line breaks in the input)—in contrast to the _block quote_ rules. * * * > 12. […] This is one more HTML table feature which _could_, and maybe _should_, be supported in the future. * * * > 13. Try `foo | bar` I did, and I would agree with _Kramdown_ on this. Not because I love _Kramdown_ so much, but because it is a “natural” consequence of the simple rules set up so far. I’m not sure if this incompatibility with most other _Markdown_ syntaxes would pose a frequently occuring problem. If so, the rules should raise the bar for a block to be recognized as a table—and I think this is one direction you’ve been aiming at multiple times. So say these restrictions: 1. A table block must be “recognizable” within the first _N_ lines (_N_ = 2 by default). 2. There must be among these lines There are obviously _a lot_ of ways to “fine-tune” the rules like this, which is one of the reasons why I’d like to have a prototype to experiment with rather sooner than _after_ a nailed-down and finished syntax which encompasses all kinds of fancy table features. * * * > 14. Syntax for a caption (i.e. table heading) is missing. (I forgot to mention that before.) There’s also no syntax for the **11** element types (apart from ``) in the content model of a _DocBook_ CALS table … ;-p Kidding aside: this can wait (as can the CALS table model). * * * **tl;dr** 1. A “parametrized rule” to limit back-tracking can easily be stated and implmented, and would probably not unduly restrict authors. 2. There is a cornucopia of “table structure features” which could be desired in a _CommonMark_ syntax (to be expressable). We can’t have them all, at least not from the start. 3. The analogy between “horizontal rules” and _table rule lines_ is not that close IMO, due on the different typographical background reflected (or to be mimicked) in both. 4. The “degenerate” table case (a 1 × 1-sized table) _should_ follow the same syntax rules, and should treat line breaks in the same way etc as a regular, “non-degenerate” table. Whether the degenerate table is actually mapped into a _table_ element in the output is a different question. 5. I think the two most important “table features” to accommodate next into the syntax are: - “column spans”, ie cells extending across multiple table columns (this would use/explore the use of “`+`” to mark this up); - “horizontal alignment” of cell content (either per cell, or for a whole column). 1. Single row and multi-row table headers and footers should be specified and dealt with in one go. 2. “row spans”, ie cells extending vertically across multiple columns should be marked up using a syntax which is consistent with “col spans”. Obviously. 3. It would be useful to have a “common table model” as the maximum feature set to express in a table syntax: this should encompass features eg from HTML, DocBook, CALS, LaTeX and whatnot. Then use this model to **prioritize** table features, and to avoid the premature introduction of conflicts with some feature needed in the future.