Proposed table specification (long!)

Simon Bull waysoftheearth at yahoo.com.au
Wed May 11 09:41:15 EDT 2011


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.

Simon


On Wed, May 11, 2011 at 9:00 PM, Michel Fortin <michel.fortin at michelf.com>wrote:


> Le 2011-05-10 à 23:54, Simon Bull a écrit :

>

> > If the proposed syntax overly complicated, I am very happy to simplify

> it.

> > The question is whether or not the following is really complicated?

> >

> > ~~~~~

> >

> >

> > -----------------------------------

> > THE PEOPLE OF MIDDLE-EARTH

> > -----------------------------------

> >

> > People Homeland Tongue

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

> > Elves Rivendell, Quenya,

> > Mirkwood, Sindarin,

> > Lorien Nandorin

> >

> > Dwarves Erebor Khuzdul

> >

> > Hobbits The Shire, Westron

> > Breeland

> >

> >

> > ~~~~~

>

> I agree with most of Fletcher's points. This is complicated. I made a

> parser that can parse something relatively similar to the above before

> settling on PHP Markdown Extra's current table syntax. I decided against it

> for a couple of reasons.

>

> First, it relies on spacing too much. With most syntaxes in Markdown, you

> can be lazy and not indent everything perfectly. This table syntax relies

> entirely on perfect spacing, which goes contrary to this principle. It also

> only work with monospace fonts which can be a problem in some cases.

>

> Second, editing its content is a real pain. Try to add a new elven tongue

> between "Quenya" and "Sindarin" and tell me how much time it takes. Now

> compare with editing the same table in HTML.

>

> I'll concede that the table is more readable than in HTML, but I think the

> ratio between usefulness and implementation effort is rather weak.

>

> And did I miss it or does it lacks one feature PHP Markdown Extra has:

> per-column left/right/center alignment?

>

>

> --

> 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/20110511/8ee32e82/attachment.htm>


More information about the Markdown-Discuss mailing list