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

[Bowerbird at aol.com]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110606/88ce820b/attachment.html>