Proposed table specification (long!)

Simon Bull waysoftheearth at yahoo.com.au
Sat May 14 21:08:04 EDT 2011


Michel and Dr.Dang both commented that it is easier to author/edit tables as
HTML than as aligned text.

I am not sure I personally agree with this, but assuming that it is true for
some significant part of the authorship, then I would like to add:

In my original post I stated my belief that the needs of the _reader_ come
before the needs of the _writer_. I don't agree that the needs of one
author outweigh the needs of five hundred, ten, or even just two readers.
The writer may well be inconvenienced once by having to align text into a
table, but the *readers* are in inconvenienced n many times by having to
read tables of HTML.

Also, I believe that using the tab key to "tab" to the next column, or use
of scripts similar to Dr.Dang's[1] to align selected text at the touch of a
hot key should alleviate much of the authoring concern.

Finally, adding support for a richer table syntax would in no way replace
the existing support for HTML -- existing markdown documents containing
tables as HTML (and other HTML) would of course continue to be valid.
Therefore, HTML enthusiasts _could_ continue to author tables in HTML if
they really could not tolerate aligning text into tables by other means.

[1]:
http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/<http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/>


Simon

On Thu, May 12, 2011 at 9:30 AM, Michel Fortin <michel.fortin at michelf.com>wrote:


> Le 2011-05-11 à 9:41, Simon Bull a écrit :

>

> > Thanks for your comments Michel.

>

> You're welcome.

>

> > In reply to the points you raise:

> >

> >

> > Regarding complexity:

> > It is not clear to me whether folks are objecting to _parsing_ complexity

> or

> > *reading/writing* complexity. Subjectively I don't think the example is

> > difficult to read; it couldn't be much simpler. So I will assume that

> > people are concerned about parsing complexity.

>

> It's pretty easy to read, no complexity problem there. I think the

> complexity lies in parsing, writing/editing, and explaining/understanding

> the possibilities.

>

> > Implementation considerations should not drive the formulation of the

> specification except

> > where some absolute technical limitation dictates otherwise.

>

> True, up to a point. It isn't worth investing tons of your time for a

> feature that'll benefit very few people (unless maybe yourself are one of

> those people, of course).

>

> > A markdown document should be *publishable* _as-is_. Wobbly mis-aligned

> > tables do not make publishable documents in any profession as far as I

> know.

>

> Well, the introduction says that indeed. Except that the role of Markdown

> is not to *enforce* this, but rather to *enable* it. And I'll say it's a

> success: most Markdown documents are indeed publishable as-is. In some

> circumstances however, the author has to make some efforts or find some tool

> to keep things pretty (multi-paragraph list items and blockquotes comes to

> mind). If you don't intend to publish the Markdown version, there is not

> much point to this effort and, thankfully, you can just skip it.

>

> > Regarding ease of editing :

> > The difficult with inserting text into a column is a general problem with

> > text editing tools and table formats in general. It is not a specific

> > problem with the proposed table syntax.

>

> My point about editing is that it's much easier to edit the HTML table than

> your table syntax because there is no grid to maintain.

>

> > Regarding cell alignment :

> > In my original post I wrote this

> >> The author has already provided the desired text alignment in the

> original

> >> (mono spaced) markdown text.

> >>

> >> It is therefore plausible for a parser to derive cell alignment by

> comparing

> >> the amount of leading and trailing white space in each table cell of

> each row

> >> and each column.

> >

> > I am the first to concede that this would require near-perfect spacing in

> > the document, and would be very hard to implement. It is therefore

> unlikely

> > that anyone would bother to implement it.

>

> Alignment deduction would likely be error prone too.

>

> > However, there's no reason not to include MMD-style cell alignment

> > meta-characters in the specification as a more practical short-cut if

> that

> > is what people want.

>

> Indeed.

>

> > Thanks again for your comments Michel -- I hope I was able to communicate

> my

> > answers effectively and politely.

>

> It's an interesting discussion.

>

> --

> Michel Fortin

> michel.fortin at michelf.com

> http://michelf.com/

>

>

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110515/cc0dd96e/attachment.html>


More information about the Markdown-Discuss mailing list