Proposed table specification (long!)

[Duke Normandin]

On Wed, 11 May 2011, Simon Bull wrote:


> Thanks for your comments Michel.

>

> 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.  On this I cannot comment

> except to say that I believe reading/writing considerations should drive the

> specification which should drive the implementation.  Implementation

> considerations should not drive the formulation of the specification except

> where some absolute technical limitation dictates otherwise.

>

>

> Regarding spacing:

> Firstly may I say that I do believe good spacing is good practice for

> tables.

> >From my original post...

> >It is the _visual alignment_ of terms into rows and columns that enables a

> reader to recognise a table.

> >Without any recognisable alignment, a reader sees a jumbled "cloud" of

> terms

> "good" doesn't have to mean "perfect", however.

>

> Secondly, as an author I take pride in producing beautiful documents.  If a

> document looks a mess then the author looks careless, lazy and less

> credible.  Additionally, from JG's introduction at Daring Fireball:

> >The overriding design goal for Markdown’s formatting syntax is to make it

> as readable as possible.

> >The idea is that a Markdown-formatted document should be publishable as-is,

> as plain text,

>

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

>

>

> 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.  Moreover, various text editors do

> support a "block" or "column" select feature which enables the author to

> select, copy, cut and paste columns (or blocks) of text.  This editor

> feature facilitates exactly the kind of operation you mentioned.

>

> That aside, the proposed table syntax supports a more trivial (lazy) method

> of inserting text into the middle of a column in a few seconds, like this:

>

> Before:

>

>       People     Homeland     Tongue

>     ====================================

>       Elves      Rivendell,   Quenya,

>                  Mirkwood,    Sindarin,

>                  Lorien       Nandorin

>

>       Dwarves    Erebor       Khuzdul

>

>       Hobbits    The Shire,   Westron

>                  Breeland

>

>

> After:

>

>       People     Homeland     Tongue

>     ====================================

>       Elves      Rivendell,   Quenya,

>                               Telerin,   <--- inserted text

>                  Mirkwood,    Sindarin,

>                  Lorien       Nandorin

>

>       Dwarves    Erebor       Khuzdul

>

>       Hobbits    The Shire,   Westron

>                  Breeland

>

>

>

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

>

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

>

>

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

> answers effectively and politely.



I want to go on record as a strong supporter of your efforts. Your
willingness to consult your peers with this brain-storming effort does
you credit! However, IMHO, at the end of the day, you must follow your
intuition and good sense after taking all informed and uninformed
opinions into consideration. I like your proposal! It will be
interesting to use your proposal in due course.

-- 
Duke Normandin
Turner Valley, Alberta, Canada