Larry Wall wrote:
This bit of POD made me think about POD's lack of tabular formatting, a common idiom in technical documentation. I know POD is still in the wings, as it were, but I wanted to say this before I forget....$_ $x Type of Match Implied Matching Code ====== ===== ===================== ============= Any Code<$> scalar sub truth match if $x($_)
The danger, of course, is that tables are a convinient way to wedge a layout system into a markup system, and given that one of POD's most elegant features is that it is just a simple markup system that has managed to avoid the temptations of layout, I would be loathe to see that change.
Still, tables are useful, so here's a simple way to get the kind of table we see above, without the HTMLish trap of pseudo-layout:
Because one of the features of POD is that documentation tends to be readable in markup form, an C<=>-introduced markup seems like it would not work well. Instead, we use C<< H<...> >> (headings) and C<< T<...> >> (table body) like so:
<> H< C<$_> | C<$x> | Type of Match Implied | Matching Code > T< Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> >
And so on... A few rules are applied:
Tables cannot be nested (this isn't a layout tool)
A table must exist entirely within one paragraph
C<< H<..> >> may occur anywhere, but some back-ends may only function correctly if it only appears once at the beginning
A literal C<|> must be escaped, as E<vb>
Any text outside of C<< H<...> >> and C<< T<...> >>, but within the same paragraph is moved outside of the table and used as "caption" for the table, as in: C<< T<a|b|c>Figure 1.T<x|y|z> >> which would render in text something like:
a b c x y z Figure 1.
and as HTML something like:
<table border=0><tr><td><table border=0> <tr><td>a</td><td>b</td><td>c</td></tr> <tr><td>x</td><td>y</td><td>z</td></tr> </table></td></tr><tr><td>Figure 1.</td></tr></table>
With some additional hooks, I would imagine, for style-sheet management of table presentation.
