More continuing text for tables

[Sherwood Botsford]

1.  Editing with non-elastic tab stops?  While Nick's idea is good, the
number of editors that support it is small.  Editors are a religious issue.
I doubt that people will switch editors in order to use MMD tables.
2.  I would like to see an option for a non-white character.  I've been
burned a few times by text processors that convert tabs to spaces.  This
will also ease the transition if you are changing the spec.
3.  For row spanning, the simplest syntax that is intuitive to me would be a
cell that has a single double-quote character.  Effectively saying 'same as
above'.
4.  Tables are one of the biggest reasons for using MMD. The ratio of tag
bytes to content bytes can be well over 1.  Matching tags is always a pain.
Even the clunkiest syntax proposed on this list has more merit than html
table tags.

My take: It aint broke.  Resist fixing it.

1.  Continue to support the pipe and multiple pipe syntax.  Cells that span
more than 3 columns are very rare, and many of these may be done with a
title instead, or be broken into multiple tables that are floated inline.

2.  Use quotes for row span.

On Wed, Jun 24, 2009 at 8:32 PM, Fletcher T. Penney <
fletcher at fletcherpenney.net> wrote:


> 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

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>

>



-- 
Sherwood Botsford
Sherwood's Forests --  http://Sherwoods-Forests.com
[Note:  THREE s's in the web link]
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090625/f583ed21/attachment.htm>