Hello List,
While translating documents in markdown, I've noticed that it is often
necessary to continue table cell text on the following line, especially when
limited to a narrow column, and especially in table headers. Unfortunately,
this is impossible with the existing table syntax, which interprets each new
line as a new table row.
I see that David Wheeler proposed a syntax for a text continuation in tables
based on database outputs (see
http://www.justatheory.com/computers/markup/markdown-table-rfc.html, and
also recent discussion on this list).
Text continuation seems to me to be a desirable addition to markdown, and
DW's proposal looks very encouraging. The outstanding arguments I could
find against his proposed ':' cell separator are:
1. Not usable as described with proportional fonts,
2. Cannot distinguish between ':' as a separator and ':' as cell
content.
I'd like to offer the following thoughts with a view to hopefully resolving
these issues.
Use With Proportional Fonts
---------------------------
The ':' syntax could work exactly as per the existing '|' cell
separator,
such that the ':' cell separator be *required* on the right of each
column
rather than optional. The last column would continue to be optional, as per
the existing '|' cell syntax.
Thus, text may be continued over any number of lines in a table body, like
this;
| Col A | Col B | Col C
---+-------------+----------+---------
1 | A1 | B1 | C1
: a2 contains : b2 : c2
: some long & : b2 : c2
: interesting : b2 : c2
2 | commentary | B2 | C2
3 | A3 | B3 | C3
Text may also be continued over any number of lines in a table header, like
this;
: This is : :
: Continued : :
: for Ages : :
| and Ages! | Col B | Col C
---+-----------+---------+---------
1 | A1 | B1 | C1
2 | A2 | B2 | C2
This works exactly the way pipe '|' currently work with both
proportional
and non-proportional fonts.
The question raised by the second example is how should markdown parsers
distinguish between a table which begins with text continuation markers, and
a list definition?
I believe this can be resolved by looking ahead to the following lines of
the document. Whether a table's compulsory '---' header/body
separator line
is encountered before a blank line should be enough to establish context.
Distinguishing Cell Separator from Cell Content
-----------------------------------------------
The existing pipe separator syntax must also have this same issue, the
difference (presumably) being that;
* The colon is used more commonly in content than the pipe, and,
* ':' is markdown syntax denoting a definition list.
1. The simplest, but most restrictive, option is to simply not support
colons within cell content. All colons, in the context of tables, are
therefore cell delimiters.
2. A less restrictive option is to require all colons within table cell
content to be formally escaped, thus '\:'. While this works
technically, it
has the disadvantage of polluting the source text.
3. An alternative option is to define the colon cell separator more exactly,
such that in the context of a table;
* Any colon encountered with leading or trailing text (e.g., 'text:'
or
':text') is not a cell separator.
* Any colon encountered exactly one or two characters after a colon
(E.g., '::' or ': :') is not a cell separator. Thus, colons
denoting cell
separators must always be at least two characters apart. This implies that
no column (excepting the first and last) can be a single character wide.
I believe that option 3 has the most appeal since it does not pollute the
source text at all, and only forces the author to create "neat" tables
in
order to work.
In any case, it seems likely that the use of colons within table content
would be rare compared to the use of text continuing across lines.
Therefore, the inconvenience caused by any of the suggested options may be
acceptable to an author who really just wants text continuing across lines!
Just a few thoughts...
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090623/6f880728/attachment.html>
Le 2009-06-23 ? 0:01, Simon Bull a ?crit :> Thus, text may be continued over any number of lines in a table > body, like > this; > > > | Col A | Col B | Col C > ---+-------------+----------+--------- > 1 | A1 | B1 | C1 > : a2 contains : b2 : c2 > : some long & : b2 : c2 > : interesting : b2 : c2 > 2 | commentary | B2 | C2 > 3 | A3 | B3 | C3Are you sure this syntax is so intuitive? I was certain (for about 5 minutes) that you meant the colons to continue the cell from the previous line, not start a new cell, despite the weird result. What David Wheeler proposed seem to follow my interpretation. Basically, here's what I saw: | Col A | Col B | Col C ==+=============+==========+========1 | A1 | B1 | C1 | a2 contains | b2 | c2 | some long & | b2 | c2 | interesting | b2 | c2 --+-------------+----------+--------- 2 | commentary | B2 | C2 --+-------------+----------+--------- 3 | A3 | B3 | C3 And here's what I believe you meant: | Col A | Col B | Col C ==+=============+==========+========1 | A1 | B1 | C1 --+-------------+----------+--------- | a2 contains | b2 | c2 | some long & | b2 | c2 | interesting | b2 | c2 2 | commentary | B2 | C2 --+-------------+----------+--------- 3 | A3 | B3 | C3 Which makes me believe my syntax above using explicit line separators may be better, even though it's much more verbose. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/
On Jun 22, 2009, at 9:01 PM, Simon Bull wrote:> * The colon is used more commonly in content than the pipe, and, > * ':' is markdown syntax denoting a definition list.Actually, it's in used for a definition list in MultiMarkdown. Markdown does not support definition lists. I have a [related proposal] [] for definition lists that's identical to what MM does, except that it uses ~ instead of :, both because it's easier to see as a bullet in many fonts, and because it's not all that common. [related proposal]: http://justatheory.com/computers/markup/modest-markdown-proposal.html Best, David
On Jun 23, 2009, at 6:43 PM, Simon Bull wrote:> Explicit row markers do _work_, but they are too verbose for my > liking. > They are more work to write, and don't read as cleanly. The colon > syntax > _works_ too, and it is cleaner, and I think having a source document > which > is natural to write, and easy to read is important.+1, although sometimes, with really busy tables, they make things clearer.> All that aside, it is support for the continued text *feature* that > I am > most interested in. If I have to live with explicit line breaks, I > guess I > will. But it would seem a shame, given the alternative.I agree, but what I mean by "busy tables" is when you have a table with multicolumn cells *and* multirow rows. My blog entry has a decent example of this: | | Grouping || +---------------+---------------------------------+ | First Header | Second Header | Third Header | +---------------+-----------------+---------------+ | Content | *Long Cell* || : continued : :: : content : :: | Content | **Cell** | Cell | : continued : : : : content : : : | New section | More | Data | | And more | And more || [Prototype table] It starts to get a little confusing in this case, so I'd like, for more complicated tables, to alternatively be able to designate rows like so: | | Grouping || +===============+=================================+ | First Header | Second Header | Third Header | +===============+=================================+ | Content | *Long Cell* || : continued : :: : content : :: +---------------+---------------------------------+ | Content | **Cell** | Cell | : continued : : : : content : : : +---------------+---------------------------------+ +---------------+---------------------------------+ | New section | More | Data | +---------------+---------------------------------+ | And more | And more || +---------------+---------------------------------+ [Prototype table] You can distinguish the one style from the other by the use of =s in the header instead of -s.> However, I strongly agree that the tilde could be used in for > definition > lists, thereby removing the ambiguity between colons used as cell > delimiters > and those used in definition lists.Thanks! They stand out better, too, in most fonts. Best, David