Tables

[Fletcher T. Penney]

As someone who has implemented something quite similar to PHP  
Markdown Extra's table syntax (but with a few more features), I have  
a couple of thoughts....

(I trimmed John's original post for brevity)

On Nov 14, 2005, at 5:20 PM, John Gruber wrote:


> My biggest gripe about PME's table syntax is the use of colons for

> marking column alignment. It seems rather against Markdown's goals

> of not having syntax elements that look like markup rules, but

> rather that everything should just look like what it is. Just

> ever-so-slightly crufty, to my eyes.

>

> So why not get rid of the colons, and do column alignment based on

> the number of spaces between the items in the column and the pipes?


I agree with hiding "cruft" to the extent possible.  For tables,  
though, I think there is a sweet spot between cruft and difficulty in  
specifying what you mean.  What I like about PME's syntax (which I  
extended in the latest version of MultiMarkdown) is that it is easy  
to make a "sloppy" table that works as expected.  If I had to align  
all of my table cells "just so" to get it to be interpreted the way I  
intended, I could see getting frustrated with that.


> So instead of:

>

>     | Height |

>     |-------:|

>     |    854 |

>     |   1050 |

>     |    960 |

>

> You'd write this:

>

>     | Height |

>     |--------|

>     |    854 |

>     |   1050 |

>     |    960 |


To be honest, to my eyes, both versions look equally "crufty."   The  
colon really doesn't stand out to me, and is not in the least  
distracting when compared to irregular column widths, etc (due to my  
font, not necessarily your typing).  Perhaps others do notice it more  
than I, however.

More important to me (as I mentioned on the comments page on my  
website), is that I would like a quick utility to take "ugly" table  
markup, and convert it to "pretty" table markup where all the pipes  
are aligned, etc.  That would be a job for a separate  **OPTIONAL**  
utility (not part of Markdown).  It would not in any way change the  
functionality of the table markup, but would make the raw text a  
little easier on the eyes.  The irregular columns bother me **FAR**  
more than the colons on a single line of text that hide between the  
hyphens and the pipes.


> The only hiccup would be centering. Not sure how this rule could

> work for that. So maybe we'd keep the colons as an option for left-

> and right- alignment, and as the only way to do column centering?


I suppose it could be optional, and it could also be a way to  
override the column setting in a single cell.  I'm not opposed to  
implementing a space based syntax, but I would not get rid of the  
colons (or some equivalent).


> Another question:

>

> Why not just require that every line of a table must start with a

> pipe (`|`)? Michel's PME implementation is existence proof that it's

> possible to write code to parse out tables even if they don't start

> with a pipe, but it seems like maybe it would make the rules easier

> to remember and simpler, and it would make it easier to see where

> tables start and end. Just throwing ideas out there.


But if it's not required by perl (and I was able to do my  
implementation, which is slightly more complicated than PME, without  
requiring leading |'s) why require it in the syntax?  This seems to  
be requiring "cruft", where above you were trying to get rid of it.

To me:

First Column	|  Second Column
----------------	| ----------------------
some data	| more data
more data	| and more date

Is less crufty and easier on the eyes than


| First Column	|  Second Column|

| ----------------		| ---------------------- |

|  some data		| more data		|

| more data		| and more date	|


Additionally, should you not use a monospaced font (as I am not now),  
the trailing pipes are even more difficult to align, and contribute  
to an irregular appearance.

Personally, when writing my table implementation, I had to concede  
that no matter what I did, tables were going to be ugly in some  
circumstances, no matter how elegant the syntax.  The gain in  
functionality, for me anyway, FAR exceeds the loss, and the sample  
tables on my don't look too bad to my eyes when viewed in raw text  
(see my comments page for examples).  Because of all this, though, I  
am glad that you are taking the time to try and choose the "right"  
syntax.  I just couldn't wait any longer, so implemented what I  
thought was a really good syntax, even if it doesn't turn out to be  
the best syntax.

In any case, the raw text looks FAR better and more accesible than  
raw HTML...


Just my thoughts....

Fletcher

PS>  Check out

	http://fletcher.freeshell.org/wiki/MultiMarkdown
and
	http://fletcher.freeshell.org/wiki/Comments_on_MultiMarkdown

for my implementation and download.  It takes PME's syntax and adds  
multiple header row's and colspans, as well as captions (thanks to  
Robert McGonegal for the caption suggestion).


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

Reality is an illusion that occurs due to lack of alcohol.
         - Anonymous


-------------- 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/20051114/5621e8c3/smime.bin