thoughts on a table specification (short! 10 simple rules!)

[Wander Nauta]

Hi Bowerbird (et al),

A few remarks...

- Using tabs to format tables will make your table look awful for
people with different tab sizes. That's why people use spaces instead
of tabs: they're always the same width. (And no, I don't think I'm an
idiot)
- If your table is so complex it needs stuff like cell merging, I
don't think it should go in Markdown.
- Making row and column headers required would annoy me greatly.
- The single to mark empty cells feels too magical for me.
- Having to include images to make sure everyone can read your
Markdown document feels... wrong.

All in all, I wouldn't really like this going in mainline Markdown.

Cheers,
Wander

On Mon, Jun 6, 2011 at 18:52,  <Bowerbird at aol.com> wrote:

> my take on a table specification.  it's short.

>

> this is for my own system, so if some of it

> doesn't seem to apply to you, that's why...

>

> ***

>

> first, the overview:  keep it simple, stupid.

>

> if your table is too big or too complex to grok

> on an iphone, then it's too big or too complex.

>

> so break it up, into a series of smaller tables.

>

> and when you do so, do it in a way such that

> an intelligent viewer-program in the future

> can "stitch" the smaller pieces back together

> when the view-port is big enough to allow it.

> (since that's what intelligent viewer-tools do.)

>

> you can draft the small tables on index cards.

> that'll give you a good sense of the right size,

> and whether each piece has enough integrity

> to stand on its own and be meaningful to us.

>

> also make sure that you can then arrange the

> smaller pieces back together into the full table.

> (make sure that any competent human would

> be able to determine how to do a reassembly.)

>

> having said all that, let's go on to the "10 rules"

> for a light-markup solution to the table problem.

>

> ***

>

> 10 "k.i.s.s." rules for light-markup tables

>

> 1.  all of the lines in a table must be contiguous.

> there must be no blank lines interrupting things.

> each table line must have a space in column 1.

>

> 2.  a table is assumed to be a "basic" table --

> where each line constitutes a row in the table.

> for tables where this is not the case, you must

> use a line of dashes for _all_ separation-lines.

> the viewer-program will draw (faint, gray) lines

> if the reader wants, regardless of what you do.

> any lines that you do include will be respected.

>

> 3.  every cell in a row must be separated from

> neighboring cells by at least 3 spaces, or 1 tab.

> (people who tell you not to use tabs are idiots.)

> if a cell is to be left empty, use a single period.

> a lone period within a cell will not be displayed;

> (the cell will get utilized as a merge candidate).

>

> 4.  the top line(s) of a table might be headers,

> which must not contain internal spaces or tabs.

> (leading and/or trailing spaces or tabs are ok.)

> further thought might allow mid-table headers,

> pending any future rule regarding cell-merging.

> either way, a mid-table line without separators

> will be interpreted to be a table-spanning line.

>

> 5.  the bottom line(s) might be footers, which

> also are not permitted internal spaces or tabs.

> this rule could be combined with #4 if there is

> future need to make room for some new rule.

>

> 6.  the leftmost column will be assumed to be

> the row-headers.  if this is not the case, then

> make the whole first column "empty" by using

> a single period in each cell in that first column.

> the first column in each row must be a space,

> since that's what indicates that this is a "block".

> so a column of dots in column 2 would be seen

> as an indication that there are no row-headers.

>

> 7.  all columns will be aligned automatically,

> according to the type of data in each column.

> 99% of the time, it's fine; embrace constraint.

> an override fluster-clucks user-comprehension.

>

> 8.  i forget what 8 was for.  (never tire of that.)

>

> 9.  aside from the rule about the separators

> -- at least 3 spaces, or 1 tab -- there are no

> other rules regarding the "look" of the table.

> use any font your heart desires. and line up

> the columns if you like, but it's unnecessary.

> the computer will make your table look nice.

> gotta believe.  plus, there's always rule #10.

>

> 10.  redundancy can often be a very good thing.

> in this vein, make a fancy version of your table,

> turn it into a graphic, and include that image-file

> in your e-book, right next to the "raw text data",

> so -- heaven forbid -- if the text just doesn't look

> the way it should, the reader has another option.

>

> ok, i've gotta stop editing this, because i just

> keep adding more elaboration, and that only

> serves to rob this nice little list of its simplicity.

>

> less is more.

>

> -bowerbird

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

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

>

>