thoughts on a table specification (short! 10 simple rules!)
info at wandernauta.nl
Mon Jun 6 13:31:07 EDT 2011
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
- 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.
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.
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
More information about the Markdown-Discuss