Tables in pure Markdown

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.


Just wanted to support the few contributors of this thread who mentioned colspan and rowspan. They are critical for technical reports and academic paper writing.

1 Like

May be core markdown is not the best place for such ideas, but here’s one to simplify creating and editing tables with long lines in cells.

| Header      | Another header     |
| short line  | very long line }_  |
| additiona}_ | they even may b }_ |
{ very long line can be continued right under the table }
{ additional lines are listed in order they appear in table (rtl, ttb) }
{ they even may be multilined
as this line }
  1. It’s readable: actual table contains enough text to get an idea of its full content, but not too much to bloat
  2. It’s editable: only “}_” is mandatory, rest of the text is just for readability; thus to change the full text, no cell editing is required. Adding new long line also doesn’t require any reordering.