More continuing text for tables

[Simon Bull]

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.


The example above _could_ be rewritten like this;

   |  This cell spans 7 cols, and looks much nicer  !
   | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
---+------+------+------+------+------+------+------+
 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |


Note the exclamation point as the last character on the first row.  I
acknowledge David's concern about the use of '!' for table structure, and
use it here only as an example.  Other punctuation marks could be
substituted.  Most, however, have the same issue -- that they are common in
text content.  This is not insurmountable.  A cell-delimiter character could
require a space either side, for example.

That aside, the example above looks more like what authors would naturally
write, and makes *much* cleaner reading than either meta-data option (to my
eyes, at least).


The introduction of a col-span indicating cell-delimiter means that *only*
the second and subsequent colspanning cells of any row require any metadata
to indicate span width.

Two (or more) colspanning cells per row would, presumably, be reasonably
rare.  When necessary, the author could use the existing multimarkdown
syntax for the narrower cells.


Simon



On Thu, Jun 25, 2009 at 3:05 AM, David E. Wheeler <david at kineticode.com>wrote:


> On Jun 23, 2009, at 10:24 PM, Simon Bull wrote:

>

>  Personally, I would prefer to use exactly one table syntax, so long as it

>> _works_.

>>

>

> Yeah, that would be my preference, as well, where "_works_" eq "is legible

> as plain text and parses properly."

>

>  Using one pipe per col to span is okay for small number of columns to

>> span,

>> though it doesn't scale elegantly, as in the following example;

>>

>>  |  This cell spans 9 cols, and therefore has 9 pipes   |||||||||

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

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

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

>>

>

> Yeah, point taken, although that'd be a pretty rare occurrence.

>

>  An alternative (or additional) syntax option might be to use an

>> alternative

>> cell separator when colspan is required.  '!' comes to mind, since it

>> looks

>> almost exactly like a '|' in most fonts. '[' or ']' are other

>> possibilities.

>>

>

> Well, ! is pretty common in text, and [ and ] are already used for links.

>

>  However, the advantage is that by default a '!' cell separator could

>> indicate colspan=2, which would likely be the most common case.  So, for

>> colspan=2, no additional pollution of the text would be required. E.g.,

>>

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

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

>> 1 |  A1  |  B1  !  C1 and D1  |  E1  !  F1 and G1  |  H1  |  I1  |

>> 2 |  A2  |  B2  |  C1  !  D2 and E2  |  F2  !  G2 and H2  |  I1  |

>>

>

> That's not very intuitive to me.

>

>  Where a colspan greater than 2 is required, metadata must unfortunately be

>> introduced.  For this I would like to suggest two alternatives;

>>

>> The first suggestion is similar to David's proposal except that it uses a

>> number of  underscores to indicate of the number of columns a cell should

>> span, such that colspan = number of underscores +2.  In the most common

>> case, colspan=2, no underscores are required.  Colspan=3 requires one

>> underscore, colspan=4 requires two underscores, and so on.

>>

>

> 3 == 1, 4 == 2? Ick.

>

>  If I *must* use metadata characters, then I prefer underscores because

>> they

>> at least "look like" part of the table frame (imagine it as part of a line

>> between two rows).  For example;

>>

>>  | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I

>>

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

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

>> 2 !_    colspan three     !  colspan two  !__        colspan four

>> 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3  |   I3

>>

>>

>> Overall, this approach requires one fewer metadata character in every

>> colspanned cell.

>>

>

> But it provides no meaning to the reader of the plain text. It just looks

> like a pasto or something. I'm opposed to adding characters with no semantic

> meaning.

>

>  The second suggestion is to use '[' as a leading cell separator, or ']' as

>> a

>> trailing cell-separator, where colspan is required.  This could be

>> followed,

>> or led, by a number x such that colspan = x.  A number need not be

>> supplied

>> where x == 2.

>>

>

> Um, no. Same problem.

>

>  This approach requires fewer metadata characters overall, but I prefer the

>> first suggestion (underscores) because it looks nicer, and reads more

>> easily.

>>

>

> I don't like either one, because they're very poor communicators of

> semantic meaning to the reader of the plain text version. Your original

> example with nine merge columns is much nicer-looking to my eye. And it's

> what MultiMarkdown already does, IIRC.

>

>

> Best,

>

> David

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

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

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090625/69d34740/attachment.html>