Tables in pure Markdown

Since community input is desired - and most people seem to vote for ‘piped’ tables - I would like to add myself to the list of those, who’d prefer a more simple style.

To me, the “first rule” of Markdown is, as expressed by Gruber (emphasis is mine):

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

To me, that means Pandoc style ‘simple’ and ‘multi line’ tables:

Simple Table:

  Right     Left     Center     Default
-------     ------ ----------   -------
     12     12        12            12
    123     123       123          123
      1     1          1             1

Table:  Demonstration of simple table syntax.

Multiline Table:

-------------------------------------------------------------
 Centered   Default           Right Left
  Header    Aligned         Aligned Aligned
----------- ------- --------------- -------------------------
   First    row                12.0 Example of a row that
                                    spans multiple lines.

  Second    row                 5.0 Here's another one. Note
                                    the blank line between
                                    rows.
-------------------------------------------------------------

Table: Here's the caption. It, too, may span
multiple lines.

I would add an optional, numeric sequence to the caption, like in the following example.

ID    Name         Street            ZIP      City         Phone
--    ---------    --------------    -----    ---------    ---------
01    Tom Smith    Main St. 324      49322    Supertown    0233-4545
02    Jane Doe     Upper Rd. 3234    23234    Homeplace    0434-1343

Table 1: Caption (optional, numeric count is also optional)

Getting tables to align correctly is difficult enough already! It seems wisest, to first add each table row, check which is the longest, and then, as a last step, format the rest of the table according to that line.

I would like this kind of table to go into the “core” spec.

Introducing | or :, already contradicts: “without looking like it’s been marked up with tags or formatting instructions” Such tables could be a “blessed extension” To those I would add other, basic, formatting symbols people came up with.

3 Likes

Where do we track the status of this being accepted into the standard or refused as a wontfix?

This feature has been talked about a lot and it seems that the time has come to move on with something like GHFM’s use of piped tables and call it good for this version and iterate as needed. Otherwise, it just appears to be stalled as a feature request and years later, we still don’t have tables in the spec.

I don’t believe there was ever a plan to add tables to the core CommonMark spec - it is categorised under “extensions” for this reason. The goal has been to finalise the core feature set first, and then consider extensions at a later point (official extensions not being a concrete plan either). GitHub Flavoured Markdown is a well supported third party extension of the core CommonMark spec which can be used today.

1 Like

Pushing this feature to an extension causes it to not be a feature of the core and then not be supported by folks who are only supporting core. It creates a lot of downstream confusion.

How would a group of folks lobby for this to be pushed into core?

1 Like

I also would be interested in this.

Tables are so common in many forms of literature, that they belong into the core.

That is also, why I vote for the simple table type, since that is unobtrusive and totally matches the Ur-Markdown spirit, IMO.

Well, tables wonʼt be part of the v1.0 core specification, but it should probably take care of special rules for the pipe character | already: CM-based GHFM requires it to be backslash-escaped even inside code spans in tables.

As soon as we have agreed upon a common way to document extensions, people should start to write specifications for their pet features which are at least as detailed as the core specification, so @jgm does not have to take care of everything.

2 Likes

Although at this point I don’t actually believe that CommonMark is going to truly improve the markdown markup. And I’m sure this has been commented on before, we at least need a way to do multiline markup, so that the raw markdown continues to be readable if a cell has a long line. I don’t really care how it’s accomplished.

Numbered rows, suggestion

   | header1 | header2
---|---------|---------
1. | cell    |
1. |         | stuff 

This would act somewhat like a numbered list putting a 1, and then a 2 respectively before each row.

I am a bit late to this discussion, but here is my 2 cents.

I somewhat like the complex table and not the simple table. My main beef with the simple table is how to recognize it as a parser when parsing. Even |----| is better because it clearly indicates that it is a table. How does the Simple Table example definitively declare itself to be a table?

On the multiline, less issues, but still some. Like the option of a newline as a row separator, but would like to have another option available as well. Questions still remain on how to deal with column and row spans for tables, as well as alignment specifications.

Pandoc doesn’t seem to have any trouble. That example is after all what Pandoc supports. If I remember correctly it’s the line that separates the header from regular rows that is key. But to be sure take a look at the Pandoc docs.

The human eye sees a table because it sees the vertical columns of white space that delineate table columns, much like it sees horizontal lines of white space (i.e. blank lines). I’ve been working on a parser that does the same. Turns out it isn’t that hard, no AI needed: simply treat any vertically aligned white space that is 2 or more characters wide as a column delimiter.

The human eye perceives blank columns much like it perceives blank lines.

1 Like

For what it’s worth, we’ve implemented an extended version of Github’s markdown tables to include multiple header rows, column spans, and row spans. Inspired by some of the ideas here but modified
based on user feedback. Our userbase of 100,000 + users seems to be pretty satisfied with this approach.

Column spans are signified by simply collapsing multiple right-hand pipes together.
Row spans are signified with a ^ immediately before the closing pipe(s).

| Head A | Spanned Header ||
| Head B | Head C | Head D |
|:-------|:------:|:------:|
| 1A     |    1B  |    1C  |
| 2A    ^|    2B  |    2C  |
| 3A    ^|    3B       3C ||
| 4A     |    4B       4C^||
| 5A    ^|    5B  |    5C  |
| 6A     |    6B ^|    6C  |

image

4 Likes

The table syntax used in Spaceship (https://github.com/jeffreytse/jekyll-spaceship) is pretty good. An addition that needs to be through through is cell wrapping.

2 Likes

This looks great! An intuitive-enough format. I would love to see this in Pandoc. When you say “we’ve implemented”, what does this mean? In some proprietary project? I’ve been monitoring Markdown reader - support new table features · Issue #6317 · jgm/pandoc · GitHub for quite some time.

We implemented it in an open-source project as an extension to Marked.js. You can find it as an NPM package at marked-extended-tables - npm

1 Like

Curious - how do you differentiate a column span from an empty cell?

| Head A | Spanned Header ||
| Head B | Head C | Head D |
|:-------|:------:|:------:|
| 1A     |    1B  |    1C  |
| 2A    ^|    2B  |    2C  |
| 3A    ^|    3B  |        |

For example, would this empty 3C cell still collapse or would it leave the cell below 2C empty? Does the collapse only happen if the pipes are consecutive without spaces between them?

1 Like

Column span only occurs if the pipes are adjacent. In your example you would just have a normal empty cell in 3C because of the whitespace between the pipes.

Sweet! Thanks. Sounds like a pretty solid solution.

This is basically a subset of what I suggested in my comment
https://talk.commonmark.org/t/tables-in-pure-markdown/81/134. I’m glad to
hear it has been working well for your users.

In addition to row/colspans, my suggested syntax included:

  • syntax for column alignments
  • a way for multiple lines to be added to a cell, allowing
    block-level constructs like lists and code blocks

I think these are both important. But getting the details right about how the
rowspan syntax works with the cell continuation syntax might be a bit tricky.

Other things people have requested:

  • syntax for row headers (not just column headers)
  • syntax for multiple header rows
  • cell-level alignment
  • syntax for specifying relative column widths
  • syntax for captions

@aoudad’s comment has a lot of nice suggestions for these:
https://talk.commonmark.org/t/tables-in-pure-markdown/81/145.

In pandoc people have also requested these features:

  • intermediate header rows (not just at the top)
  • table footer

It’s very tricky to figure out what is the right level of complexity to
suport.

Actually, I think the table syntax that is most compatible with the Markdown
philosophy of prioritizing source readibility is grid tables:
https://pandoc.org/MANUAL.html#extension-grid_tables. Pipe tables look
increasingly like line noise the more features are added, while grid tables
look just like tables. But grid tables seem quite unpopular due to the need to
align columns.

1 Like

This is basically a subset of what I suggested

Yep that’s where I got most of the structure from. It seemed the “cleanest” out of everything I saw, and was easy to lay over the top of existing GFM standard tables without breaking what is already out there.

As for your other items:

  • syntax for column alignments

My syntax allows column alignments following the GFM standard of colons and dashes.

  • a way for multiple lines to be added to a cell

My syntax simply concatenates adjacent row-spanned cells together with a space. This allows the user to use all of the vertical space in a row-spanned group but yes, it does not allow multiline blocks.

Would it be worth supporting pipe tables only for simple cases? If your table gets to a certain level of complexity and is becoming unreadable it is probably a good idea to switch from pipe to grid tables.

This would be line with other Markdown features, for example setext headings are only supported for h1 and h2, requiring the writer to switch to atx style for h3-6 headings.