Tables in pure Markdown

agreed, as long as this simplified form is also supported:

 Header  | Another header 
 field 1 | something      
 field 2 | something else


Table caption
Column 1 | Column 2 | Column 3 | Column 4
1        | 2        | 3        | 4
five     | six      | seven    | eight
9        | 10       | 11       | 12
thirteen | fourteen | fifteen  | sixteen


One issue with tables is how they look on devices with smaller screens (e.g. smartphones). Whereas code blocks can be wrapped and large images can be swapped out with smaller resolution images, tables are difficult to shrink without becoming hard to read. With this in mind, I’m glad that tables are an extension as there are sometimes better ways of listing the same data in a reflowable way.

If tables are to be used, the Typify Markup syntax looks good.

github/markdown-extra/kramdown do support a quite rich table syntax that is widespread and regular, why focusing on a new markup? The extra “table caption” feature seems wrong to me.

The HTML5 spec explains how captions might be used. I think captions could be a worthwhile feature. Otherwise the Typify Markup syntax is very similar to the syntax in Markdown flavours which include tables.

As long there is consensus and that part could be set in stone I’d be happy:

header+footer+caption and matching the typify/markdown-extra/kramdown general markup?

I am a bit concerned with some talk in this topic of aligning column information to the left or right (with colons on the second line to mark alignment). This is a presentational feature which belongs in CSS. Or if the writer types numbers in a column, the parser could be smart enough to align the contents of the column to the right (if that is indeed the requirement) by adding a CSS class automatically.


I also think that CommonMark must have tables. Markdown is great but I was always bored that tables were not part of the specifications.


@hftmarkand Tables, strikethrough and other features will likely be considered as CommonMark extensions once the core spec is complete. The core spec is intended just to be the features found in the original Markdown spec, which excludes tables. See this discussion for more details.

@chrisalley that would be sad, if improving markdown ten years later, I would expect to have all the non-standard markdown features as commonmark core features.

If not, we will still have dozens of extensions implemented or not…

The main idea is that you have core+extensions implemented in the reference implementation. But you need to sort your priorities.

  • get the core commonmark features rock solid (takes some time but not much discussion anymore)
  • get the most wanted extension ironed out (takes lots of discussion to get full agreement)

Markdown without tables is a complete non-starter for my needs; using Markdown as a sort of HTML table macro is one of its primary benefits (especially since right-aligning a numeric table column is much more work than it should be in HTML). I doubt I’m alone, or even the minority.

The simple pipe syntax is obviously the least surprising approach (though fenced TSV or CSV or JSON arrays of arrays would be very useful to display as tables), even though it may have some inconveniences. It’s intuitive, and it has precedence.

I think the “settle the core first” argument is a false choice, a purely artificial bottleneck. There ought to be enough participation to work on more than a single thing at a time.

1 Like

Considering it has been literally a DECADE since the last “spec” release for Markdown, I am not sure I agree.

1 Like

It is better to have the core spec set in stone and then have standard extension to it. The work on both can be in parallel.

Fair enough, but I guess I’m more optimistic about the CommonMark effort. It organizes and provides momentum that wasn’t really there before (was almost disparaged in many ways, by the only available authority then).

I just want to throw weight behind the case for one - any - of the justified tables to be in the spec as soon as possible, not just html insertion.

I’m visiting here as a commercial user of MD and no real sort of developer. I believe ours is a typical use case for Markdown; we don’t use it just to make creating html easier, we use it because 50% of our users will look at resulting html and 50% will read the .md or .txt in its raw form, in a monospace font in something like NP++ We love Markdown because we can make both equally legible.

A largish table is tricky to produce using pipe-dash or similar, but worth it’s weight in gold over trying to read a html table in the .md

If there is a pressing need to add tables, I suggest that your developers adopt a popular flavour in the meantime (GitHub’s table syntax for example). It might be a while before the CommonMark table extension syntax is decided upon; the focus right now is to solidify the core. I’m sure that someone will write a conversion script if CommonMark goes with different syntax (or you could just use GitHub Flavored Markdown for legacy documents).

1 Like

I believe markdown-it has a tables extension, but interprets "core"
syntax in conformity to commonmark. So it might be a good solution
for you while the spec is being developed.

1 Like

Tables looks good in “markdown-it” demo:

Seems like pipes and dash will be the way to go, once core is settled.

1 Like

I don’t see why multiple table syntaxes couldn’t be supported (the same way Markdown has multiple lists, headers, and links). GitHub-style tables are common, but Pandoc includes some minimalist tables which might be preferable if the writer wishes to avoid page clutter. E.g.

 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

It would be preferable to use CSS or some automated mechanism for aligning the columns though. HTML does not encourage the writer to include presentational information for a reason; I don’t think CommonMark should either.


markdown-it has no multililne tables support only because CM spec not exists. We selected GH as the most common and which will not became broken after spec available.