More continuing text for tables

[David E. Wheeler]

On Jun 24, 2009, at 4:27 PM, 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.


Yeah, but merging a given row of them into one column is much less  
common.


> 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.


Also not useful in the plain text. I'm all for affordances for the  
parser if their semantic value is apparent. Such is not the case here:  
the "7" is spurious and looks like a typo.


> 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.


It's not about obtrusiveness as much as meaning.


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

> natural to

> either the author or the reader.


Right.


> 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  |


Yes, better, though I might make both the right and left columns  
different.


> 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).


Agreed. But I'm not sure how many special cases we really want. They  
can be hard to remember when writing such a table. It seems to me that  
we should start with a design with *no* special cases and then see  
what cow paths develop.


> 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.


I think I'd rather write it in HTML.


> 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.


If there is an existing syntax that works, why add the special case?

Best,

David