Proposed table syntax

Lou Quillio public at quillio.com
Thu Oct 21 19:49:36 EDT 2004


> How about a vertical pipe followed
> by at least one whitespace character:
>
> 	| Company					Description
> 	| ===========================================================
> 	| Apple Computer inc.		The maker of the Macintosh, iPod,
> 	| 						Quicktime and Firewire.
> 	| -----------------------------------------------------------
> 	| Microsoft				No need for a description.
> 	| 						More lines here
>
> That would also allow for the reuse of the `=` and `-` for `<thead>`
> and `<tr>` delimiters respectively.

Tables are an interesting question for Markdown; good to be getting into it
finally.  The prior art (earlier pseudocode implementations) are
instructive, but somehow miss the mood of MD, I think.

Maybe a good starting point is to cordon-off table data with a unique
character at line start, and pipe's a good choice (whatever else is decided
for columns).  Or tilde.

It could be a rule that consecutive lines begining with pipe comprise a
contiguous table.  An optional header row might have two pipe characters.

You can see where I'm going here, John.  Tables are complex blocks and
justify a unique switch.

I should add that my brilliant friend MichelF's example can [almost] be
rendered as a styled <dl>.  Perhaps <dl>s and <table>s must be taken
together.  Matrices of unlimited column-count have rows begining with X
unique character (tables), and matrices limited to two columns (definition
lists) -- though potentially multiple sub-rows -- have another.

LQ


++++++++++++++++++++++++++++++++++++
Lou Quillio
public at quillio.com
++++++++++++++++++++++++++++++++++++



Quoting Shaun Inman <markdown at shauninman.com>:

> > I wonder if it'd be unwise to use `=` signs as the header delimiter,
> > since they're already used for headers. More on this later.
> I was thinking that they were a good choice *because* they're already
> used for headers. I do recognize that that would make it much more
> difficult to implement though. What I find odd is that there's been no
> resistance to suggesting that the table be tabbed in once given the
> conflict with code blocks--maybe the indentation was just
> misinterpreted as a sample code block?
>
> Despite the conflict I think there should to be something that indents
> the table from the rest of the copy. How about a vertical pipe followed
> by at least one whitespace character:
>
> 	| Company					Description
> 	| ===========================================================
> 	| Apple Computer inc.		The maker of the Macintosh, iPod,
> 	| 						Quicktime and Firewire.
> 	| -----------------------------------------------------------
> 	| Microsoft				No need for a description.
> 	| 						More lines here
>
> That would also allow for the reuse of the `=` and `-` for `<thead>`
> and `<tr>` delimiters respectively.
>
> >
> >
> > * * *
> >
> > Michel Fortin <michel.fortin at michelf.com> wrote on 10/20/04 at 1:24pm:
> >
> >> First, sometime I prefer to fit my text in a table on more than one
> >> line. A row separator could be useful in that case:
> >>
> >>   Company                 Description
> >>   ===========================================================
> >>   Apple Computer inc.     The maker of the Macintosh, iPod,
> >>                           Quicktime and Firewire.
> >>   -----------------------------------------------------------
> >>   Microsoft               No need for a description.
> >>   -----------------------------------------------------------
> >>                           Multiple paragraphs?
> >>
> >>                           *   And lists?
> >>
> >>                               And why not code blocks.
> >>
> >>> Noticed the empty cell beside
> >>> this one?
> >>   -----------------------------------------------------------
> >
> > This pushes the line out a bit. I'd have to think about this. How
> > frequently do people really need multiple paragraphs and lists and
> > blockquotes inside a table? (Not counting someone using tables for
> > page layout, of course, which isn't applicable to Markdown at all.)
> >
> > It's not that I don't think this is a nice idea. And it looks
> > Markdown-y. I just don't want to add support for these features if
> > they're only going to be used seldomly.
> >
> >
> > * * *
> >
> > Jelks Cabaniss <jelks at jelks.nu> wrote on 10/20/04 at 2:20pm:
> >
> >> Precedents exist.  See for example [reStructuredText]'s,
> >> [Grutatext]'s and
> >> [TexTile]'s implementations.
> >>
> >> [reStructuredText]: http://tinyurl.com/5s7mk#tables
> >> [Grutatext]: http://www.triptico.com/download/README_grutatxt
> >> [TexTile]: http://www.textpattern.com/help/?item=table
> >>
> >> Personally, I prefer the first two -- which are quite similar.
> >
> > My problem with Grutatext- and reST-style tables is that they're too
> > complicated. There's no way Markdown should support things like
> > rowspans and colspans. For that sort of thing, it's better and
> > easier to just write raw HTML.
> >
> > I think all the `|` pipes end up getting noisy, visually. I think
> > the reason they use them is to allow for the column and row spanning
> > -- that sort of thing would be difficult or maybe even impossible to
> > parse if you were just using spaces and tabs to separate table cells.
> >
> > The same goes for Textile's syntax, with regard to the pipes.
> >
> > reST's "simple" table style is a little closer to what might work
> > for Markdown.
> >
> >
> > * * *
> >
> > Angie Ahl <alists at vertebrate.co.uk> wrote on 10/20/04 at 7:45pm:
> >
> >> regex wise I'd say a cell separator (</td><td>) should be one or more
> >> tabs and possibly, more than 1 space( but I can see problems with
> >> that.
> >
> > Requiring tabs would indeed make it easier to parse -- as you point
> > out, using "more than 1 space" would make it easy to add a cell
> > break by mistake. However, as Lou Quillio pointed out, tabs are
> > problematic for anyone typing in a web browser textarea field.
> >
> > That said, Markdown is not optimized for people writing in textarea
> > editors. It's optimized for people writing in decent text editors.
> > But, if I had to guess, I'd wager that textarea fields are the most
> > popular place where Markdown is used.
> >
> > So if we separate cells with whitespace, I think it'll have to work
> > with both spaces and tabs. Maybe three-or-more spaces, instead of
> > two-or-more?
> >
> >
> >> Doing it with 1 or more tabs leads to a problem if there were empty
> >> cells, you'd need to mark a cell as empty, maybe with something like
> >> [empty]
> >
> > Empty cells are a big problem if we want to use whitespace to
> > separate cells. (This is another reason why reSt, Grutatext, and
> > Textile use `|`s, I'll bet.)
> >
> >
> > -J.G.
> > _______________________________________________
> > Markdown-discuss mailing list
> > Markdown-discuss at six.pairlist.net
> > http://six.pairlist.net/mailman/listinfo/markdown-discuss
> >
>
> _______________________________________________
> Markdown-discuss mailing list
> Markdown-discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>



More information about the Markdown-discuss mailing list