More continuing text for tables

[Simon Bull]

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


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  |


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.

I don't mind whether we use the leading or trailing cell-delimiter for this,
but in my examples below, I mostly use a leading cell delimiter.

The disadvantage of using another type of cell delimiter is that it
introduces additional table framework into our text.

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  |


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.

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.


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.

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 [3    colspan three     [  colspan two  [4        colspan four
 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3  |   I3

would be exactly equivalent to

   | 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    3]  colspan two  ]         colspan four         4]
 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3  |   I3  |


This approach requires fewer metadata characters overall, but I prefer the
first suggestion (underscores) because it looks nicer, and reads more
easily.



Simon

On Wed, Jun 24, 2009 at 12:23 PM, David E. Wheeler <david at kineticode.com>wrote:


> On Jun 23, 2009, at 6:43 PM, Simon Bull wrote:

>

>  Explicit row markers do _work_, but they are too verbose for my liking.

>> They are more work to write, and don't read as cleanly.  The colon syntax

>> _works_ too, and it is cleaner, and I think having a source document which

>> is natural to write, and easy to read is important.

>>

>

> +1, although sometimes, with really busy tables, they make things clearer.

>

>  All that aside, it is support for the continued text *feature* that I am

>> most interested in.  If I have to live with explicit line breaks, I guess

>> I

>> will.  But it would seem a shame, given the alternative.

>>

>

> I agree, but what I mean by "busy tables" is when you have a table with

> multicolumn cells *and* multirow rows. My blog entry has a decent example of

> this:

>

> |               |            Grouping            ||

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

> | First Header  |  Second Header  |  Third Header |

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

> | Content       |           *Long Cell*          ||

> : continued     :                                ::

> : content       :                                ::

> | Content       |    **Cell**     |          Cell |

> : continued     :                 :               :

> : content       :                 :               :

>

> | New section   |      More       |          Data |

> | And more      |             And more           ||

>  [Prototype table]

>

> It starts to get a little confusing in this case, so I'd like, for more

> complicated tables, to alternatively be able to designate rows like so:

>

> |               |            Grouping            ||

> +===============+=================================+

> | First Header  |  Second Header  |  Third Header |

> +===============+=================================+

> | Content       |           *Long Cell*          ||

> : continued     :                                ::

> : content       :                                ::

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

> | Content       |    **Cell**     |          Cell |

> : continued     :                 :               :

> : content       :                 :               :

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

>

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

> | New section   |      More       |          Data |

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

> | And more      |             And more           ||

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

>  [Prototype table]

>

> You can distinguish the one style from the other by the use of =s in the

> header instead of -s.

>

>  However, I strongly agree that the tilde could be used in for definition

>> lists, thereby removing the ambiguity between colons used as cell

>> delimiters

>> and those used in definition lists.

>>

>

> Thanks! They stand out better, too, in most fonts.

>

> Best,

>

> David

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090624/325d9930/attachment.htm>