More continuing text for tables

[David E. Wheeler]

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