Proposed table specification (long!)

[David Parsons]

>

> On Sun, May 15, 2011 at 2:01 PM, I wrote:

>

>   I presume that the readers will be reading the

> entire document in html, via a viewer that renders

> html into a more pleasing format.


On May 14, 2011, at 10:43 PM, Simon Bull wrote:

>

> However, what if you want to include a markdown document, or even  

> just a fragment of markdown, in an email?   It might be forwarded to  

> many readers without ever being published as HTML.  What if you want  

> to write markdown for the purpose of a discussion group like this  

> one?  It might be read by hundreds of readers without ever being  

> published as HTML.

>

> Additionally, if you would like to see markdown as a supported input  

> format for tools such as wikis, forums, blogs, issue management  

> systems, and so on (in fact, any tool where the source document  

> itself can be retrieved, reviewed, and updated/edited inline) then  

> your source document will possibly be read and reread by many users  

> over the life time of the document.

>

> Perhaps these scenarios are worth considering too?


     I believe you are grasping at straws here.    Now, there's  
certainly nothing horribly wrong with your proposed implementation,  
but I do wish to restate that you would be much better off writing  
some code that implements your
proposal.   It doesn't even have to do a full markdownification of the  
output; a skeleton that takes as input a
document and translates your table blocks into html would be  
sufficient (and there are some markdown implementations
that support a "please markdownify me!" flag for html block elements;   
if you add those flags to your generated
html, you will have a program that can be pipelined like:

     simontable < document.text | markdown > document.html

     Don't convince us with words.  Convince us with code.

     -david parsons