This is there instruction manual: http://research.microsoft.com/en-us/um/people/daan/madoko/doc/reference.html#sec-strike-out
This is their main site: https://www.madoko.net/
We could possibly check them out and see what considerations can be taken from their syntax. Their pipe tables syntax is quite complex.
e.g. This is how they do block maths
~ Equation {#eq-gaussian}
\int_{-\infty}^\infty e^{-a x^2} d x = \sqrt{\frac{\pi}{a}}
~
It looks like they’ve used the ~ WORD construction to play the role of LaTeX commands and environments. In general I’m not a fan of using English words like Equation to mark structural elements. It’s unnatural in documents that aren’t in English.
That makes sense.
What about the way they do their tables? Anything you like or dislike?
Tables: their syntax inherits a problem that many markdown table syntaxes have: you can’t have multiple lines (or block level content) in table cells. This is a pretty big limitation. reStructuredText, and pandoc’s multiline tables and grid tables, do better in this regard.
I agree with @jgm on literal markup which just camouflages LaTeX or HTML. It’s not in the spirit of Markdown and hence Commonmark. Many flavors/extensions and other lightweight markup languages went down that dark path.
Madoko intermingles presentation and structure, but so does Markdown (to a lesser degree) and basically everything else.
It’s an interesting idea to distinguish ~ and - and = in table markup, but why not treat - and * and _ differently in horizontal rules or +, - and * in lists or _ and * in emphasis markup?
Madoko’s \/ convention may be useful sometimes and there maybe two or three other good, original ideas in there, but overall it looks like a hodgepodge.
Seems like the \/ convention is similar to a inline “no markdown island” that people here are trying to sort out. Don’t know if that’s still an issue or if no-markdown is sorted out already here.
can’t have multiple lines (or block level content) in table cells
Then you might be interested in an example table syntax from a blog article on potential table syntax (Which was found from Madoko syntax reference manual).
And that blog suggest an approach for multiline pipe tables, of using : to indicate that a row is part of a cell above (Based on PostgreSQL table display). (Other interesting concept to note, is the idea of detecting cell alignment via number of spaces instead of |----:|.)
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
But yea Madoko didn’t adopt it for some reason. Maybe it’s harder to parse?
An interesting comment on the bottom of the blog mentions this approach instead:
BTW, PostgreSQL has changed its format a bit since I wrote this. The syntax for continued lines is better, I think. The colons are gone, and now they just use a + right-aligned to show that a column continues to the next line:
id | name | desciption | 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 given a concept of perhaps making parser simpler by still keeping the | divider, but adding a + modifier to indicate a lookahead for multirow cell.
I like the multiline pipe table syntax in your example. In fact I prefer the earlier (abandoned) syntax with the colons to the new syntax, because it makes the cells stand out more visually, and because I can imagine inadvertent results with the new syntax (e.g. if someone has a single column with + and - signs). I don’t see much difficulty parsing either variety.
Note that pandoc’s simple and multiline tables detect column alignment via spacing of the headers. They also detect relative column sizes that way. Pandoc doesn’t allow different cells in a column to have different alignments. It’s hard to imagine real-use cases where this would be wanted.
Just for the banter: I run into this scenario in certain assessment feedback sheets for tertiary education. A table sets out in grid form the marking criteria; x in the cell is usually centered; left- or right-justified can add nuance on performance.
Admittedly, this is a fairly niche case.