More continuing text for tables

[Fletcher T. Penney]

I can't say that I find this proposal to be perfect, but to me this was 
one of the more compelling emails in this thread.

I have been having my own internal conversation about how to rewrite the 
MMD table syntax.  My personal goals were to find a way to minimize the 
markup, make it more readable/less distracting, and hopefully easier to 
generate.


I started thinking seriously about how to rewrite the table syntax after 
reading about [elastic 
tabstops](http://nickgravgaard.com/elastictabstops/).  To me, these 
seemed to be the best way to implement tabs within text documents.

Then, it occurred to me that the only time I use tabs in MMD documents 
is at the beginning of a line, to indicate code blocks, or to indent 
lists.  I never use tabs within a line.

Yet tabs are inherently what I want to use to align columns of text in 
tables.

So I started looking into using tabs to separate columns within a table 
(i.e. replacing the | in the current MMD syntax).  If you used spaces 
before the tab, you could ensure that each row had the same 
column-widths (for sure with monospace font, and fairly tolerant for 
some variation with other fonts, but definitely not perfect).  If your 
editor used elastic tabstops, the plain text table would look right, and 
  it would be easily converted to an XHTML table.

It doesn't solve the colspan or rowspan issue.  My personal thoughts are:

* I like the idea of one colspan per row - more than that, and maybe you 
should just use HTML.  This would allow a simpler syntax.

* I am increasingly unconvinced that I should worry about rowspans, and 
require HTML for that.

* Every editor should support a standardized approach to elastic 
tabstops.  Too bad I can't make this happen.


Keeping in mind that my own goal for MMD is to provide an easy to write/ 
easy to read syntax for the 80-90% of tables that people write, at the 
expense of requiring HTML for the other group of complicate tables out 
there, I think there is hope for a table syntax built (almost?) entirely 
out of whitespace markers.


Thoughts?


F-




Simon Bull wrote:

> Okay, thanks for your input, David.

> 

> Tables with lots of narrow columns are not so rare they can be 

> dismissed; they are useful for matrices of numbers, for example.

> 

> How about an (entirely optional) addition to the existing multimarkdown 

> pipe syntax, specifically for cells which span many cols?  A number 

> followed immediately by a pipe would be taken as the colspan.

> 

> So this;

> 

>    | This cell spans 7 cols, and has less spa |||||||

>    | ColA | ColB | ColC | ColD | ColE | ColF | ColG |

> ---+------+------+------+------+------+------+------+

>  1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |

> 

> would be exactly equivalent to this;

> 

>    |   This cell spans 7 cols, and has more space  7|

>    | ColA | ColB | ColC | ColD | ColE | ColF | ColG |

> ---+------+------+------+------+------+------+------+

>  1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |

> 

> It contains 1 ugly metadata character, true.  It is a matter of personal 

> taste as to whether you find 6 additional pipes or 1 digit more 

> intrusive, so why not provide authors with the choice?  The advantage of 

> the digit meta-character, of course, is the additional space in the cell 

> to write content.

> 

> 

> The real problem is that *neither* of these options is entirely natural 

> to either the author or the reader.

> 

> 

> Thinking some more, I realise that neither metadata option is required 

> at all to parse a table row correctly when there is only a single 

> colspan cell in a row _if_ we have a distinct cell-delimiter which 

> denotes a colspanning cell.

> 


-- 
Fletcher T. Penney
fletcher at fletcherpenney.net

Every so often, I like to go to the window, look up, and smile for a
satellite picture.
	- Steven Wright
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3290 bytes
Desc: S/MIME Cryptographic Signature
Url : <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090624/0ac9d546/attachment-0001.bin>