Extended Table Syntax
I have a suggestion for an extended Table Syntax for MultiMarkdown. I think it is simple enough to justify its use without bloating the syntax. Please tell me what you think about it. Regards, jakov
### Pipe Style Tables
* In addition to the colspan feature of MultiMarkdown, *rowspan* could be provided using `^` instead of a bar. In the following example the fruits will each span two rows:
```
| Fruit | Advantages |
| --------- | ---------------- |
| Bananas | built-in wrapper |
^ | bright color |
| Oranges | cures scurvy |
^ | tasty |
```
* Similarly, to enable multi-line content for table cells, I propose to use the apostrophe (`'`) to widen the cell vertically for writing. This will however not affect the rowspan, but provide a way to use block elements inside a table cell! Compare also a [proposal in the discussion list](http://six.pairlist.net/pipermail/markdown-discuss/2009-June/001600.html) (which I stumbled upon after my initial idea, that's why i used `'` instead of `:`. Also in my version the cells get extended *below*.).
The following table should result in the exactly the same output as the grid table example above (even the col width should be the same), with a list for each of the fruits' advantages:
```
| Fruit | Price | Advantages |
| ------------- | ------------- | ------------------ |
| Bananas | $1.34 | - built-in wrapper |
' ' ' - bright color '
| Oranges | $2.10 | - cures scurvy |
' ' ' - tasty '
```
As you can see, there's no mixing of apostrophes and bar symbols in a line as this would lead to confusion for both the user and the parser.
* Exchanging the dashes with equal signs should set the whole column to be header elements. Thus, in the following the fruits should be contained in `<th>`-elements. It would be best to also add the `scope="row"` attribute (For the normal headers `scope="col"` should be used).
```
| Fruit | Price | Advantages |
| ============= | ------------- | ------------------ |
| Bananas | $1.34 | - built-in wrapper |
' ' ' - bright color '
| Oranges | $2.10 | - cures scurvy |
' ' ' - tasty '
```
* As it was already proposed on the Markdown discussion list, numbers next to the finishing bar will be interpreted like multiple bars. E.g. `| cell 7|` will be the same as `| cell |||||||` (with seven bars on the right). To 'escape' this behavior, just place a blank before the pipe: `| cell 7 |` will say 'cell 7'.
```
|a |b |c |d |e |f |
|--|--|--|--|--|--|
|r |s |t 3|u |
|v |w 4|x |
```
```
|a |b |c |d |e |f |
|--|--|--|--|--|--|
|r |s |t |||u |
|v |w ||||x |
```
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by jakov on 07 Jun, 2013 07:09 PM
unfortunately my code-blocks didn't get parsed as markdown. However, the advantage of "pipe style tables" (as i call them) is that they don't need monospaced font. I hope you get the meaning of my examples even unformated. You can copy them to plaintext and insert the spaces to align the bars to get a better visual representation.
Support Staff 2 Posted by fletcher on 07 Jun, 2013 09:06 PM
Thanks for writing in with your proposal. Tables are a complicated thing to extend. Everyone has their own pet idea, but they are generally not very intuitive to people who didn't create them.
I threw your post into MultiMarkdown Composer so I could properly format the tables and be sure I was looking at what you intended. The problem with the first two tables is that it's not immediately clear to what the symbols are for, and it's easy at a glance to miss that there are apostrophes in the second table. Now arguably, that's good, since it's not distracting. But it would be easy to mis-copy a table and then wonder why it wasn't looking like you intended.
The "======" proposal may be feasible at first glance.
The proposal at the end for extending cells by using a number would be really prone to error and is unlikely to be useful in real life use. When reading the source, unfamiliar users would wonder what the numbers mean.
I will think about the "====" proposal. I'll go ahead and reject the "cell 7|" proposal. As to the first two ideas, it's unlikely that I will implement them:
It will be labor intensive to properly extend a parser to handle multirow table cells. Perhaps not impossible, but ridiculously complex. For example, a bold phrase that extends across two rows in a table would be difficult to parse as bold. A list spanning multiple rows of text would have to be tracked for indenting to allow sublists. I could go on, but you probably begin to see how much of a challenge this would be.
A rowspan marker by itself is simple, but as soon as I implement it, somebody will use it for a multirow cell, and then wonder why it doesn't work.
Even if I managed to do it, then there's the complexity of block level elements inside a table across output formats (e.g. LaTeX, ODF, etc.) This may or may not be feasible.
The reality is that it's not currently realistic to expect MMD to support tables of arbitrary complexity.
I have never (or at least almost never) personally needed a table to have more than I could accomplish with MMD as it stands. And if I don't need something crazy, it's unlikely to make it into MMD. If I want something, it's much more likely to get included, even if it is crazy. ;)
For those reasons, it's really unlikely that I will add rowspan/multirow table cells now, or in the future. But I'll keep your proposal in mind if I do.
3 Posted by Jakob on 11 Jun, 2013 02:51 PM
I understand that there are many different table formats. Pandoc uses gridtables and whitespace tables (they call it simple tables), for example. However, for pipe style tables (as i would call MD extra style in general) i feel that there are not that many options. At least i bave not seen another similar proposal. Of course, i don't have to stick to the symbols i chose, just the mechanism matters.
Adittionally, i think these features can be implemented on after the other.
I chose "^" as the most logical symbol to point upwards. It's easy to replace a "|" with a "^" to merge two cells without breaking the rest of the table and vice versa.
I chose "'" on purpose to look similar to the pipe. It would be visually easier to use no symbol at all, but this would require monospaced font and white space align (the major drawback of pandocs tables). The idea of extending cells downwards is not only to allow block elements (maybe only later) but to ease writing longer text into a cell without making the text table extremely wide.
I dont know how exactly you are parsing the tables. Is it line by line? I have coded the features in my js pandoc at github (the online demo doesnt work, but offline works fine). Actually, parsing these tables is a lot easier than similar features in grid tables or whitespace tables! But yes, my code "waits" for the whole table to be analysed before parsing each cells' content. Like that there is also no problem with multirow cells.
Regards, jakov
Am 07.06.2013 um 23:06 schrieb "fletcher" <[email blocked]>:
Support Staff 4 Posted by fletcher on 12 Jun, 2013 03:36 PM
Jakob,
I suspect that adding proper syntax highlighting to a table structure of this sort would be very difficult (though presumably not impossible). One would have to compile the various lines into a single table, pull out the text from extended cells to make a new string of the contents of each cell, apply the parsing to determine syntax highlighting needs, and then split the cell back into its component lines so that the highlighting can be applied back into the cell, which spans multiple lines. For example, I span of bold that crosses two (or more) lines, would have to be split into multiple bold spans to cover each of the contiguous strings.
It's a slightly different (and more complicated) problem than just converting the text into HTML, and I have to consider both aspects. Practically speaking, my guess is that it would not be worth the time and effort, so something like MultiMarkdown Composer would have to simply not apply any syntax highlighting inside tables. It could still be used in the HTML/LaTeX output, of course, but not in the editor itself.
That said, it's still an uphill battle to convince me to extend the table syntax in this sort of a way. Don't get me wrong, I understand that some people need complex tables. And I'm sure at least one person has used each of the 10,000 unnecessary features included in something like MS Word. But I strongly believe that the beauty and power of Markdown is its simplicity. I am trying to hang onto that in MMD as well. HTML and LaTeX both offer very powerful table support, so in that sense complex tables are already supported. At some point, the syntax used by a markup language to provide all of these table features will approach the complexity of the underlying HTML/LaTeX. So why not just use that instead? Table support in MMD is not intended to cover every use case. But I think it does a phenomenal job of covering simple tables that most commonly come up in "regular" life (not for academics, or complex business documents, etc.)
There may be the "perfect" hybrid syntax out there somewhere, and I'm perfectly willing to keep looking at proposals. But the one that is going to win me over is the one that is elegant, simple, intuitive, unambiguous, and doesn't look like computer markup. It's a tall order... In my opinion, no one has adequately solved this problem yet.
Fletcher
On Jun 11, 2013, at 10:51 AM, Jakob <[email blocked]> wrote:
5 Posted by Jakov on 14 Jun, 2013 12:53 PM
I have to admit, that I have not thought about syntax highlighting and i
admit that it doesn't look easy. However, I think that any table syntax
that is sufficiently intuitive will have this problem. I don't think it
is more convenient to have really long table cells break the line like that:
| ibewui asdf | poiusa dsaf | lkjna eaf |
|---------|-----|--------|
| Lorem ipsum dolor sit amet, cu cibo minim his. | Nostro
..sapientem vituperatoribus ei has. | Consul iracundia
..repudiandae duo eu. |
| No legimus incorrupte adversarium duo. | Ius mutat
..molestiae ut. | Argumentum adversarium no sit. |
I also think that it might be even more difficult to have text-editors
or markdown editors break the lines at multiple positions like this:
| ibewui asdf | poiusa dsaf | lkjna eaf |
|---------------|------------------|------------------|
| Lorem ipsum | Nostro sapientem | Consul iracundia |
.. dolor sit ..vituperatoribus ..repudiandae duo
..amet, cu cibo ..ei has. ..eu.
..minim his. .. ..
| No legimus | Ius mutat | Argumentum |
..incorrupte ..molestiae ut. ..adversarium no
..adversarium .. ..sit.
On the other hand, it would be cool to have this for writing --
independently of whether this gets saved to the source file or not. The
drawback would be that other editor (who are not capable of doing so)
will get very long lines again.
I would nevertheless argue, that Markdown is intended to be a kind of
syntax highlighting in itself. Markdown should even be useable with
notepad.exe or any other bad texteditor. Therefore i think it would be
only a little drawback if tables don't have highlighting in multiple
rows. The first rows (or non-extended cells) could still have normal
highlighting. Only breaking syntax or syntax in the following lines
(marked with either "^" or " ' ") would be omitted. Again, you could
introduce the features one by one, i.e. no syntax higlighting in
extended cell at first but maybe later.
My point of writing tables even in slightly more complex for into a
markdown file is that you then have one source file. Can you put an HTML
table into a MMD file and get LaTex output for that table?
Did you get any other table syntax proposals recently ? Could you point
me to any of them? I'd really like to see their advantages and drawbacks.
6 Posted by Jakov on 14 Jun, 2013 01:47 PM
(i forgot to mention something:)
I have also thought about syntax for Pandoc's "simple tables" and "grid
tables". I've noted my concepts here:
https://github.com/jakov/js-pandoc/blob/master/concepts.md and some of
it is (partially buggy) already working, as you can see here:
http://jakov.github.io/js-pandoc/demo.html
Coding the MMD-like extended tables is a lot easier than the fixed-width
tables. What I want to point you to is that neither these two other
syntax styles would allow for easy syntax highlighting.
Regards,
jakov
Support Staff 7 Posted by fletcher on 14 Jun, 2013 06:04 PM
> My point of writing tables even in slightly more complex for into a
> markdown file is that you then have one source file. Can you put an HTML
> table into a MMD file and get LaTex output for that table?
If you use the XSLT to convert HTML -> LaTeX (the only way to do LaTeX in MMD 2, but not really used by most people in MMD 3/4), you could use HTML tables to create LaTeX tables, but the tables still had to be fairly simple. I suppose one could update the XSLT to handle more complex tables thought.
You are correct that complex tables written in HTML will not work in LaTeX, and vice-versa. But the sample complexities will sometimes have to be addressed when converting to RTF, OpenDocument, Word, etc.
> Did you get any other table syntax proposals recently ? Could you point
> me to any of them? I'd really like to see their advantages and drawbacks.
I occasionally get emails with table syntax proposals. The ones that are public would either be on the support site or the MultiMarkdown discussion list.
http://groups.google.com/group/multimarkdown/
http://support.fletcherpenney.net/
F-
Support Staff 8 Posted by fletcher on 14 Jun, 2013 06:29 PM
(The "dingus" doesn't seem to do anything.)
As to the many ideas about tables in the `concepts.md` file, a few thoughts.
* perhaps a slight exaggeration, but there are almost as many syntaxes for tables as the original Markdown has for all of its features... ;)
* it would be very difficult for multiple developers to correctly implement these features in multiple programming languages, leading to even more of a "tower of babel" effect in the "Markdown family"
* I suspect this is yet another "scratching one's own itch" area --- I just don't care that much about complex tables. I rarely need them. I think they are often overused and unnecessary, but that's clearly a sweeping overgeneralization that is not always true. I doubt that many current "Markdown family" developers will have the motivation/interest in implementing all of these features in the "leading" variants. Which means they will be relegated to second tier Markdown variants that lack support in most tools
* Some of the proposals are very unambiguous (e.g. Grid Style). However it would be a nightmare to type by hand. What about when you decide to insert a line, or a cell, etc.?
* I think the part of the difficulty is trying to apply a successful solution to a problem it wasn't designed for. Markdown, and it's descendants, are fantastic for text. Those of us who get it realize that it orders of magnitude better than Word for most documents. That said, Markdown would not be particularly useful for programming a spreadsheet, or drawing a blueprint. In this case, writing tables brings a different set of problems and design needs than straight text. For most of us, writing text in Markdown is *easier* than writing in Word. It's more intuitive. It's faster. It's more "cross-platform." For writing a complex table, however, I suspect that using Word, OpenOffice, Excel, Pages, etc. would be easier. You want cells that expand to fit their content. You want to be able to merge/split cells, etc. It's really hard to do that in a plain text editor by hand. Imagine writing one of these on your cell phone.
* My personal opinion is that a bunch of us can spend a lot of time creating ever more complex ways of trying to represent a table of arbitrary complexity in plain text. Some solutions will be better than others. But my suspicion is that none will really ever be good enough, when measured not just on their ability to mimic a complex table as ASCII-art, but instead when measured on their ease of creation by a human using a dumb text editor (e.g. Notepad). I'm not convinced that most of the proposals are easier than the traditional standard (e.g. Word).
* My proposal would instead be to try and redefine the problem. What is the exact problem you are trying to solve? If you were starting from scratch, how would you solve that problem? Is trying to shoehorn this into Markdown/MultiMarkdown/Pandoc/etc. the best approach. Do we need something else? What would that something else look like? Embedding an image of the table? Something else? I think something "revolutionary" is more likely to be successful than something "evolutionary" in this arena.
F-
9 Posted by Jakob on 15 Jun, 2013 08:04 PM
|----------------|-------|
| \|nest\|test\| | some |
' \|----\|----\| ' text '
' \|one \|two \| ' here '
Von: fletcher <[email blocked]>
An: [email blocked]
Betreff: Re: Extended Table Syntax [Suggestions #10]
// Please reply above this line
==================================================
From: fletcher (Support staff)
(The "dingus" doesn't seem to do anything.)
As to the many ideas about tables in the `concepts.md` file, a few thoughts.
* perhaps a slight exaggeration, but there are almost as many syntaxes for tables as the original Markdown has for all of its features... ;)
* it would be very difficult for multiple developers to correctly implement these features in multiple programming languages, leading to even more of a "tower of babel" effect in the "Markdown family"
* I suspect this is yet another "scratching one's own itch" area --- I just don't care that much about complex tables. I rarely need them. I think they are often overused and unnecessary, but that's clearly a sweeping overgeneralization that is not always true. I doubt that many current "Markdown family" developers will have the motivation/interest in implementing all of these features in the "leading" variants. Which means they will be relegated to second tier Markdown variants that lack support in most tools
* Some of the proposals are very unambiguous (e.g. Grid Style). However it would be a nightmare to type by hand. What about when you decide to insert a line, or a cell, etc.?
* I think the part of the difficulty is trying to apply a successful solution to a problem it wasn't designed for. Markdown, and it's descendants, are fantastic for text. Those of us who get it realize that it orders of magnitude better than Word for most documents. That said, Markdown would not be particularly useful for programming a spreadsheet, or drawing a blueprint. In this case, writing tables brings a different set of problems and design needs than straight text. For most of us, writing text in Markdown is *easier* than writing in Word. It's more intuitive. It's faster. It's more "cross-platform." For writing a complex table, however, I suspect that using Word, OpenOffice, Excel, Pages, etc. would be easier. You want cells that expand to fit their content. You want to be able to merge/split cells, etc. It's really hard to do that in a plain text editor by hand. Imagine writing one of these on your cell phone.
* My personal opinion is that a bunch of us can spend a lot of time creating ever more complex ways of trying to represent a table of arbitrary complexity in plain text. Some solutions will be better than others. But my suspicion is that none will really ever be good enough, when measured not just on their ability to mimic a complex table as ASCII-art, but instead when measured on their ease of creation by a human using a dumb text editor (e.g. Notepad). I'm not convinced that most of the proposals are easier than the traditional standard (e.g. Word).
* My proposal would instead be to try and redefine the problem. What is the exact problem you are trying to solve? If you were starting from scratch, how would you solve that problem? Is trying to shoehorn this into Markdown/MultiMarkdown/Pandoc/etc. the best approach. Do we need something else? What would that something else look like? Embedding an image of the table? Something else? I think something "revolutionary" is more likely to be successful than something "evolutionary" in this arena.
F-
Having trouble reading this? View this discussion online: Extended Table Syntax.
Reply with #ignore to stop receiving notifications for this discussion.
Support Staff 10 Posted by fletcher on 16 Jun, 2013 12:52 AM
Jakob,
Thanks for writing.
No worries about browser compatibility. I was actually using Chrome, but might be the same issue as Safari.
Why do you say tables got "badly scrambled?" in Composer. When you type a tab inside a table, it does add a tab and a pipe so that the table aligns properly. In fact, you can create a simple table only having to type the initial pipe to start a table, and then tabs/return/letters to create the rest. Combined with elastic tabstops, I've never seen an easier way to create MMD or PHP Markdown Extra tables that look great in the source as well.
F-
--
Fletcher T. Penney
[email blocked]
11 Posted by Jakov on 16 Jun, 2013 08:53 AM
I think i was testing a table that didn't have tabs in it already.
Therefore, pointing the cursor just before the pipe and then pressing
tab resulted in the "weird" behaviour of creating an additional pipe. Of
course, it's sufficiently easy to delete these extra pipes.
With "badly scrambled" i meant that with the soft wrap the lines aren't
clear anymore when the source panel is too small or the table is too
large. I think you should either mark the wrapped lines in a different
style or symbol (like many text editors do). Alternatively, you could
highlight the colomn you are just in for the whole table: i.e. if the
cursor is in the 3rd cell of one row, then also each 3rd cell of the
other rows will get highlighted.
I really love elastic tabstops, but i feel they are not sufficiently
spread throughout different text editing software. I would therefore
suggest to (optionally) save the "elastic tabstops" with blanks before
them to make them easily readable in other editors (with mono-spaced
font) too. Sublime text has a plugin that does exactly that, because
there was no way of integrating real elastic tabstops.
some_text--->elastic
more.....--->stuff
jakov
Support Staff 12 Posted by fletcher on 16 Jun, 2013 12:33 PM
Jakov,
Yes. If you have lines that are longer than the width of your window, they will soft wrap. There is nothing I can do about this --- in Composer v1 I experimented with not wrapping lines inside tables, which caused all sorts of strange behavior and wasn't worth it. You can always buy additional monitors and have the document window spread across 3 displays, which should allow you to have pretty wide tables that are all perfectly aligned. ;) Or you can shrink the font down to 6 pt and use a magnifying glass....
Again, there are limits to the expression of arbitrarily complex/wide tables in a plain text format, particularly when you are limiting the width of the tables.
Elastic tabstops are a ridiculously elegant solution to a big problem. I don't understand why more editors aren't using them. There is a script that can be used to clean up MMD tables for viewing in "dumb" text editors in a monospace font:
https://github.com/fletcher/MMD-Support/blob/master/Utilities/table_cleanup.pl
But elastic tabstops are a much better solution.
Support Staff 13 Posted by fletcher on 18 Jun, 2013 08:27 PM
Latest push to github supports '=====' for designating a table column as a header.
fletcher closed this discussion on 18 Jun, 2013 08:27 PM.
Jakob re-opened this discussion on 20 Jun, 2013 09:09 PM
14 Posted by Jakob on 20 Jun, 2013 09:09 PM
Cool! :)
Thinking in this direction i d like to ask if there is a way for setting table footers (as in html)? I know your syntax if a single blank row for additional bodies. Is the last body always the footer?
If not so, i would suggest using the dashes row again like this:
Head | head
---------|---------
Body| body
---------|---------
Footer|footer
Alternatively, underlines fir the footer:
Head | head
---------|---------
Body| body
_______|______
footer|footer
Am 18.06.2013 um 22:27 schrieb "fletcher" <[email blocked]>:
Support Staff 15 Posted by fletcher on 21 Jun, 2013 05:19 PM
There is not currently a footer feature for tables.
I'll consider this for the future.
F-
16 Posted by KS on 09 Oct, 2013 02:17 PM
So, is there such a thing as a cell spanning multiple rows in MultiMarkdown at this time?
Support Staff 17 Posted by fletcher on 09 Oct, 2013 02:19 PM
No. Just multiple columns. I have yet to see a suitable proposal for a syntax for cells spanning multiple rows.
F-
--
Fletcher T. Penney
[email blocked]
18 Posted by KS on 09 Oct, 2013 03:15 PM
Thanks Fletcher. Is the issue just syntax, or use cases?
Support Staff 19 Posted by fletcher on 09 Oct, 2013 03:46 PM
Syntax. I haven't seen anything that is suitably:
1) Simple to write with a "dumb" text editor
2) Easy to read if you're not familiar with the syntax
3) Looks natural, and not too much like computer markup
4) Reasonably easy to parse
F-
--
Fletcher T. Penney
[email blocked]
20 Posted by duongtu on 24 Jun, 2014 02:47 PM
Hi Fletcher,
I really appreciate your work in Multimarkdown which really helpful with its "Multi Features".
For the lack of 'row span' feature, I don't see anyone has mention to the table syntax of TexTile (http://redcloth.org/textile/page-layout/#tables)
Textile
|{background:#ddd}. Cell with background|Normal| |\2. Cell spanning 2 columns| |/2. Cell spanning 2 rows|one| |two| |>. Right-aligned cell|<. Left-aligned cell|
Why don't we use the number instead of the number of symbol for cell spanning issue?
Thanks,
Tu
Support Staff 21 Posted by fletcher on 25 Jun, 2014 06:43 PM
That looks even less like something I would type in an email to a friend to represent a table.
F-
22 Posted by Julián on 14 Nov, 2014 03:32 PM
What about just using "^"?
For example,
| | Divisible | Indivisible |
| - | :------------------: | :-------------------------------: |
| A | initial + subsequent | jointly & severally for entire harm |
| B | subsequent | ^ |
[Proximate Subsequent Act Liability Chart]
Support Staff 23 Posted by fletcher on 17 Nov, 2014 07:17 PM
When I see, that I think that the intent is to repeat the above line (like a "same here").
24 Posted by jakov on 17 Nov, 2014 08:37 PM
Spanning cells *are* a way of saying "same here" most of the times, aren't they?
If one would like to repeat the content of the cell above, one could easily use copy and paste, or use a different syntax: I would suggest {...}, but I doubt that it is necessary.
Jakov
On 17. November 2014 20:17:18 MEZ, fletcher <[email blocked]> wrote:
25 Posted by gomezbiagi on 17 Nov, 2014 11:06 PM
That's a legitimate interpretation of that notation. For my charts, when
it's important to have duplicate text in multiple cells, I'll definitely
copy and paste. When it's important that two cells lead to the same
cell/conclusion, I'll use ^ to mean that it's a continuation of the meaning
above. I guess how important the distinction is depends on whether one
thinks there's a difference between cells that say the same thing and a
vertical cell that spans more than one row.
Cheers,
Julián
On 2014-11-17 3:37 PM, "jakov" <
[email blocked]> wrote:
26 Posted by jakov on 18 Nov, 2014 06:13 PM
+1. I just wanted to point out that it's just a small difference, not something that would result in entirely unexpected results.
The only difficulty is how to handle combinations of rowspan and colspan. In my opinion colspan would get defined in the first line as "| ... ||" and in the second line the number of trailing bars in "| ^ |||" would not change anything.
27 Posted by WilliamUset on 23 May, 2016 01:45 PM
Magnificent job! Merrilee
28 Posted by WilliamUset on 07 Jun, 2016 10:43 PM
Thanks for sharing, this is a fantastic forum.Really looking forward to read more. Keep writing. Buess