Aaron Sherman <[EMAIL PROTECTED]> wrote: > 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($_)> >
I worry that, with that syntax, someone might try to nest a table. I also think that the H<>/T<> syntax is a bit wrong--to use CSS terminology, tables are a block construct, not an inline one.[1] Instead, I'd recommend something like this: =table C<$_> | C<$x> | Type of Match Implied | Matching Code =row Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> (I'm not sure how good the alignment is on that--Gmail's compose window uses a variable-width font.) This makes it syntactically impossible to nest a table, removes the slightly odd-looking H<>/T<> syntax, and is still very readable. It's also not dependent on the distinction between tabs and spaces (see 'make' for why this is a Good Thing). To help deal with wide tables, lines that don't have a =table/=row directive (but do have other content) would be appended to the previous line: =table C<$_> | C<$x> | Type of Match Implied | Matching Code =row Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> [1] Actually, in CSS a table is neither an inline nor a block construct--it's considered its own category, because normal block constructs have a default width of 100%, while tables are only wide enough to hold their contents. Same difference... -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker There is no cabal.
