1. Editing with non-elastic tab stops? While Nick&#39;s idea is good, the number of editors that support it is small. Editors are a religious issue. I doubt that people will switch editors in order to use MMD tables.<br>
2. I would like to see an option for a non-white character. I&#39;ve been burned a few times by text processors that convert tabs to spaces. This will also ease the transition if you are changing the spec.<br>3. For row spanning, the simplest syntax that is intuitive to me would be a cell that has a single double-quote character. Effectively saying &#39;same as above&#39;.<br>
4. Tables are one of the biggest reasons for using MMD. The ratio of tag bytes to content bytes can be well over 1. Matching tags is always a pain. Even the clunkiest syntax proposed on this list has more merit than html table tags.<br>
<br>My take: It aint broke. Resist fixing it.<br><br>1. Continue to support the pipe and multiple pipe syntax. Cells that span more than 3 columns are very rare, and many of these may be done with a title instead, or be broken into multiple tables that are floated inline.<br>
<br>2. Use quotes for row span.<br><br><div class="gmail_quote">On Wed, Jun 24, 2009 at 8:32 PM, Fletcher T. Penney <span dir="ltr">&lt;<a href="mailto:fletcher@fletcherpenney.net">fletcher@fletcherpenney.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I can&#39;t say that I find this proposal to be perfect, but to me this was one of the more compelling emails in this thread.<br>

<br>
I have been having my own internal conversation about how to rewrite the MMD table syntax. My personal goals were to find a way to minimize the markup, make it more readable/less distracting, and hopefully easier to generate.<br>

<br>
<br>
I started thinking seriously about how to rewrite the table syntax after reading about [elastic tabstops](<a href="http://nickgravgaard.com/elastictabstops/" target="_blank">http://nickgravgaard.com/elastictabstops/</a>). To me, these seemed to be the best way to implement tabs within text documents.<br>

<br>
Then, it occurred to me that the only time I use tabs in MMD documents is at the beginning of a line, to indicate code blocks, or to indent lists. I never use tabs within a line.<br>
<br>
Yet tabs are inherently what I want to use to align columns of text in tables.<br>
<br>
So I started looking into using tabs to separate columns within a table (i.e. replacing the | in the current MMD syntax). If you used spaces before the tab, you could ensure that each row had the same column-widths (for sure with monospace font, and fairly tolerant for some variation with other fonts, but definitely not perfect). If your editor used elastic tabstops, the plain text table would look right, and it would be easily converted to an XHTML table.<br>

<br>
It doesn&#39;t solve the colspan or rowspan issue. My personal thoughts are:<br>
<br>
* I like the idea of one colspan per row - more than that, and maybe you should just use HTML. This would allow a simpler syntax.<br>
<br>
* I am increasingly unconvinced that I should worry about rowspans, and require HTML for that.<br>
<br>
* Every editor should support a standardized approach to elastic tabstops. Too bad I can&#39;t make this happen.<br>
<br>
<br>
Keeping in mind that my own goal for MMD is to provide an easy to write/ easy to read syntax for the 80-90% of tables that people write, at the expense of requiring HTML for the other group of complicate tables out there, I think there is hope for a table syntax built (almost?) entirely out of whitespace markers.<br>

<br>
<br>
The real problem is that *neither* of these options is entirely natural to either the author or the reader.<br>
<br>
<br>
Thinking some more, I realise that neither metadata option is required at all to parse a table row correctly when there is only a single colspan cell in a row _if_ we have a distinct cell-delimiter which denotes a colspanning cell.<br>