Tables

[Fletcher T. Penney]

On Nov 15, 2005, at 7:21 PM, Jelks Cabaniss wrote:


> Michel Fortin wrote:

>

>

>>

>>      |            | Imported      || Domestic

>>      |            | Beans | Peas  || Carrots | Tomatoes

>>      |            | ----- | ----- || ------- | --------

>>      | Wholesale  | $1.00 | $1.25 || $1.20   | $1.20

>>      | Retail     | $2.00 | $3.00 || $1.80   | $1.80

>

>

> vs

>

>

>>      |            | Imported     || Domestic          ||

>>      |            | Beans | Peas  | Carrots | Tomatoes |

>>      |            | ----- | ----- | ------- | -------- |

>>      | Wholesale  | $1.00 | $1.25 | $1.20   | $1.20    |

>>      | Retail     | $2.00 | $3.00 | $1.80   | $1.80    |

>

>

> I personally much prefer the second one -- it looks more "natural",  

> hurts my

> eyes and brain much less.  The multiple pipes are only where  

> they're needed.

>

> If it were a colspan of, say, more than 3, that could indeed get  

> messy.  I

> would think we might want an alternate method -- instead of  

> `||||||||`,

> something more like `-8|` ...

>

> /Jelks


I agree on this one - The first option somehow implies that one of  
the dividers is "special" and deserving of two pipes.  There is  
nothing unique about that divider, and therefore the symbolism is non- 
intuitive.  In fact, until you mentioned a couple of examples, I  
didn't even see how the system worked.  (Not a good thing for a  
simple markup language....)  I can't even begin to imagine creating a  
table with several layers of nested columns using this system.  Also,  
if you decide to "nest" after the fact, you have to change every  
single column in the table, rather than just the row you changed.

The second option makes total sense.  If a given cell spans more than  
one column, it **is** special, and therefore deserves a special symbol.

To me, the question is not which option to use (of these two, the  
choice seems obvious, though I am certainly open to other ideas).   
The question is how to make the second less ugly (note that I didn't  
say pretty) when spanning lots of cells.  And this is where the  
"Markdown as email text" analogy breaks down - I don't currently see  
how it can remain quite as elegant as the rest of Markdown when it  
comes to creating tables.  But I really feel that tables are too  
important not to include in Markdown, and they will remain in  
MultiMarkdown (in fact, I added some new features to the  
MultiMarkdown syntax and a bug fix or two - it should be released  
later tonight...)


I really hope all this discussion leads  to an overall consensus on  
the best available syntax, and that tables make it to Markdown.  I'm  
happy to keep working on MultiMarkdown and adding the features that  
are otherwise unavailable, but I would love it if MultiMarkdown  
became unnecessary...  ;)

Fletcher


-- 
Fletcher T. Penney
fletcher at alumni.duke.edu

When childhood dies, its corpses are called adults.
     - Brian Aldiss


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3949 bytes
Desc: not available
Url : http://six.pairlist.net/pipermail/markdown-discuss/attachments/20051115/6549f870/smime-0001.bin