More continuing text for tables

Simon Bull waysoftheearth at yahoo.com.au
Wed Jun 24 01:24:54 EDT 2009


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>


More information about the Markdown-Discuss mailing list