Tables

[Michel Fortin]

Le 2005-11-14 à 17:20, John Gruber a écrit :


> So I needed a table for my PowerBook review last week, and the  

> laziest way to write it seemed to be to use PHP Markdown Extra  

> (PME). I wrote it like this:

>

>     |Display                    | Width | Height | PPI |

>     |---------------------------|------:|-------:|----:|

>     |12-inch PowerBook/iBook    |  1024 |    768 | 107 |

>     |14-inch iBook              |  1024 |    768 |  91 |

>     |15-inch PowerBook G4 (new) |  1440 |    960 | 115 |

>     |15-inch PowerBook G4 (old) |  1280 |    854 | 103 |

>     |17-inch PowerBook G4 (new) |  1680 |   1050 | 117 |

>     |17-inch PowerBook G4 (old) |  1440 |    960 | 102 |

>     |20-inch Cinema Display     |  1680 |   1050 |  99 |

>     |23-inch Cinema Display     |  1920 |   1200 |  98 |

>     |30-inch Cinema Display*    |  2560 |   1600 | 102 |


The first thing I thought when I saw that table is "did John just  
coded this by hand?"... then I saw the right-aligned columns and I  
was sure they were not. (Who would write an `align="right"` by hand  
for every cell?)

So it left two possibilities, John used PHP Markdown Extra, or just  
added tables to  Markdown.


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


I agree with this sentiment. I talked about using spacing in the  
discussion last March, just in a different way to make things less  
ambiguous. You may remember this concept which use a space instead of  
a colon:

     |Display                    | Width | Height | PPI |
     |---------------------------|------ |------- |---- |
     |12-inch PowerBook/iBook    |  1024 |    768 | 107 |

In the end, when making the syntax for PHP Markdown Extra, I decided  
not to use this. The problem is that it's easier to set it wrong by  
accident, and it's not that much nicer than using colons. Using colon  
however ensure the intent of the author is never misinterpreted. You  
can't write a colon there by accident.


> You'd write this:

>

>     | Height |

>     |--------|

>     |    854 |

>     |   1050 |

>     |    960 |

>

> and Markdown would "know" that the column should be right-aligned

> because every item is one space from the right side. Whereas if it

> were:

>

>     | Height |

>     |--------|

>     | 854    |

>     | 1050   |

>     | 960    |

>

> It'd be left-aligned.

>

> Seems like this should work even for people who are editing in

> variable-width fonts.


Unless they use tabs. And using tabs is probably the only way to  
align columns properly with a variable-width font.

My way to think about it is that by relying on spacing for alignement  
you increase the risk of unexpected results. It's a nice idea, but we  
must be careful with it. For example, this overspaced table could be  
a problem:

     |  First     |   Second    |
     | ---------- | ----------- |
     |    1.0     |      1.2    |
     |   23.2     |     24.1    |

I'm not sure you could find a *reliable* algorithm to find the  
expected alignement here (assuming it could have been written in a  
variable-width font) because you can't just count the spaces on the  
left and on the right and say we should align cells on the side where  
there is more space.


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


Which seems to be the best compromise, but at the same time I think  
it greatly diminish the value of having "intelligent" alignement  
since you cannot use it to you remove the other unpleasant-to-the-eye  
syntax.

Another drawback is that it would probably work badly for right-to- 
left languages. But I'm not sure if anyone use it in these situations.


> * * *

>

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


For which I would reuse your own words:


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


Does a table still looks like a table when the first character is not  
a pipe? I think so! As for many other things in Markdown, you aren't  
required to make things readable in plain text.


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/