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.
Can you share the data and or anecdotes behind that observation?
I don’t have data, this is just my memory of conversations going back many years.
Basically there’s a split in the Markdown community between people who use Markdown for long-form writing (documentation, articles, books) and those who use it mainly for things like Reddit or Stack Overflow comments. For the latter, grid tables are a problem because they are working in text boxes which often use proportional-spaced fonts, so lining anything up is next to impossible.
I assume when you say block-level, you’re excluding just chunking an HTML <br> in the table to create a newline - this works on SO/SE, which makes for useful formatting in tables even without bullets.
I’ve used grid tables on SO/SE (posts, not comments)… the only way they work is if you put them in a code fence so that they’re fixed width. It does work, and we did it for years before we implemented markdown tables… but my thumbs definitely got tired from all of the spaces you needed to use to keep everything aligned.
I will say, there were some perks to it that you can’t really replicate in MD tables.
You could align things pretty much wherever you wanted. Want the header to be centered and the column content to be right aligned? No problem, just change the spacing.
Looks pretty in a fixed-width preview. Trying to review a MD table without a live preview is… not fun (for me, anyway). If your text entry pane is already in fixed width anyway, what you see is what you get - without fancy programming and no need to check your preview.
So, they’re not terrible and they do have some functionality that’s nice.
One of the biggest asks we’ve seen from community members (and one of my biggest frustrations) has been the ability to control the column width which is separate than column span. I don’t know that I’ve seen much discussion of this and I’m not sure whether there’s a viable solution to allow people to call out a max column width, for example (either in percentages or px).
One of the biggest asks we’ve seen from community members (and one of my biggest frustrations) has been the ability to control the column width which is separate than column span. I don’t know that I’ve seen much discussion of this and I’m not sure whether there’s a viable solution to allow people to call out a max column width, for example (either in percentages or px).
Pandoc does have a system for this.
For grid, simple, and multiline tables, widths are calculated based on the widths in the source.
For pipe tables, if one of the lines extends beyond 72 columns (configurable), then relative widths are calculated based on the widths of the separator lines.
A markdown editor might offer to import CSV, TSV, … files into markdown tables, but those data formats should not become a valid table syntax themselves, because their human readability is severely impaired.
I pulled the syntax ideas from this thread, so thanks for having this discussion here. I didn’t add things like row headers or multi-line headers, since i wanted to keep the implementation fairly unobtrusive and i figure that those can be added on independently.
Just FYI, GitHub do support tables which interrupt a paragraph, although they don’t seem to state this explicitly in their GFM spec (see Tables (extension)) for some reason.