Re: More continuing text for tables
On Jun 24, 2009, at 4:27 PM, Simon Bull wrote: Okay, thanks for your input, David. Tables with lots of narrow columns are not so rare they can be dismissed; they are useful for matrices of numbers, for example. Yeah, but merging a given row of them into one column is much less common. How about an (entirely optional) addition to the existing multimarkdown pipe syntax, specifically for cells which span many cols? A number followed immediately by a pipe would be taken as the colspan. Also not useful in the plain text. I'm all for affordances for the parser if their semantic value is apparent. Such is not the case here: the 7 is spurious and looks like a typo. It contains 1 ugly metadata character, true. It is a matter of personal taste as to whether you find 6 additional pipes or 1 digit more intrusive, so why not provide authors with the choice? The advantage of the digit meta-character, of course, is the additional space in the cell to write content. It's not about obtrusiveness as much as meaning. The real problem is that *neither* of these options is entirely natural to either the author or the reader. Right. Thinking some more, I realise that neither metadata option is required at all to parse a table row correctly when there is only a single colspan cell in a row _if_ we have a distinct cell-delimiter which denotes a colspanning cell. The example above _could_ be rewritten like this; | This cell spans 7 cols, and looks much nicer ! | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | Yes, better, though I might make both the right and left columns different. Note the exclamation point as the last character on the first row. I acknowledge David's concern about the use of '!' for table structure, and use it here only as an example. Other punctuation marks could be substituted. Most, however, have the same issue -- that they are common in text content. This is not insurmountable. A cell-delimiter character could require a space either side, for example. That aside, the example above looks more like what authors would naturally write, and makes *much* cleaner reading than either meta-data option (to my eyes, at least). Agreed. But I'm not sure how many special cases we really want. They can be hard to remember when writing such a table. It seems to me that we should start with a design with *no* special cases and then see what cow paths develop. The introduction of a col-span indicating cell-delimiter means that *only* the second and subsequent colspanning cells of any row require any metadata to indicate span width. I think I'd rather write it in HTML. Two (or more) colspanning cells per row would, presumably, be reasonably rare. When necessary, the author could use the existing multimarkdown syntax for the narrower cells. If there is an existing syntax that works, why add the special case? Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Jun 23, 2009, at 10:24 PM, Simon Bull wrote: Personally, I would prefer to use exactly one table syntax, so long as it _works_. Yeah, that would be my preference, as well, where _works_ eq is legible as plain text and parses properly. Using one pipe per col to span is okay for small number of columns to span, though it doesn't scale elegantly, as in the following example; | This cell spans 9 cols, and therefore has 9 pipes | | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI | ---+--+--+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | H1 | I1 | Yeah, point taken, although that'd be a pretty rare occurrence. An alternative (or additional) syntax option might be to use an alternative cell separator when colspan is required. '!' comes to mind, since it looks almost exactly like a '|' in most fonts. '[' or ']' are other possibilities. Well, ! is pretty common in text, and [ and ] are already used for links. However, the advantage is that by default a '!' cell separator could indicate colspan=2, which would likely be the most common case. So, for colspan=2, no additional pollution of the text would be required. E.g., | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI | ---+--+--+--+--+--+--+--+--+--+ 1 | A1 | B1 ! C1 and D1 | E1 ! F1 and G1 | H1 | I1 | 2 | A2 | B2 | C1 ! D2 and E2 | F2 ! G2 and H2 | I1 | That's not very intuitive to me. Where a colspan greater than 2 is required, metadata must unfortunately be introduced. For this I would like to suggest two alternatives; The first suggestion is similar to David's proposal except that it uses a number of underscores to indicate of the number of columns a cell should span, such that colspan = number of underscores +2. In the most common case, colspan=2, no underscores are required. Colspan=3 requires one underscore, colspan=4 requires two underscores, and so on. 3 == 1, 4 == 2? Ick. If I *must* use metadata characters, then I prefer underscores because they at least look like part of the table frame (imagine it as part of a line between two rows). For example; | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I ---+---+---+---+---+---+---+---+--- +--- 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | H1 | I1 2 !_colspan three ! colspan two !__colspan four 3 | A3 | B3 | C3 | D3 | E3 | F3 | G3 | H3 | I3 Overall, this approach requires one fewer metadata character in every colspanned cell. But it provides no meaning to the reader of the plain text. It just looks like a pasto or something. I'm opposed to adding characters with no semantic meaning. The second suggestion is to use '[' as a leading cell separator, or ']' as a trailing cell-separator, where colspan is required. This could be followed, or led, by a number x such that colspan = x. A number need not be supplied where x == 2. Um, no. Same problem. This approach requires fewer metadata characters overall, but I prefer the first suggestion (underscores) because it looks nicer, and reads more easily. I don't like either one, because they're very poor communicators of semantic meaning to the reader of the plain text version. Your original example with nine merge columns is much nicer-looking to my eye. And it's what MultiMarkdown already does, IIRC. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
Okay, thanks for your input, David. Tables with lots of narrow columns are not so rare they can be dismissed; they are useful for matrices of numbers, for example. How about an (entirely optional) addition to the existing multimarkdown pipe syntax, specifically for cells which span many cols? A number followed immediately by a pipe would be taken as the colspan. So this; | This cell spans 7 cols, and has less spa ||| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | would be exactly equivalent to this; | This cell spans 7 cols, and has more space 7| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | It contains 1 ugly metadata character, true. It is a matter of personal taste as to whether you find 6 additional pipes or 1 digit more intrusive, so why not provide authors with the choice? The advantage of the digit meta-character, of course, is the additional space in the cell to write content. The real problem is that *neither* of these options is entirely natural to either the author or the reader. Thinking some more, I realise that neither metadata option is required at all to parse a table row correctly when there is only a single colspan cell in a row _if_ we have a distinct cell-delimiter which denotes a colspanning cell. The example above _could_ be rewritten like this; | This cell spans 7 cols, and looks much nicer ! | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | Note the exclamation point as the last character on the first row. I acknowledge David's concern about the use of '!' for table structure, and use it here only as an example. Other punctuation marks could be substituted. Most, however, have the same issue -- that they are common in text content. This is not insurmountable. A cell-delimiter character could require a space either side, for example. That aside, the example above looks more like what authors would naturally write, and makes *much* cleaner reading than either meta-data option (to my eyes, at least). The introduction of a col-span indicating cell-delimiter means that *only* the second and subsequent colspanning cells of any row require any metadata to indicate span width. Two (or more) colspanning cells per row would, presumably, be reasonably rare. When necessary, the author could use the existing multimarkdown syntax for the narrower cells. Simon On Thu, Jun 25, 2009 at 3:05 AM, David E. Wheeler da...@kineticode.comwrote: On Jun 23, 2009, at 10:24 PM, Simon Bull wrote: Personally, I would prefer to use exactly one table syntax, so long as it _works_. Yeah, that would be my preference, as well, where _works_ eq is legible as plain text and parses properly. Using one pipe per col to span is okay for small number of columns to span, though it doesn't scale elegantly, as in the following example; | This cell spans 9 cols, and therefore has 9 pipes | | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI | ---+--+--+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | H1 | I1 | Yeah, point taken, although that'd be a pretty rare occurrence. An alternative (or additional) syntax option might be to use an alternative cell separator when colspan is required. '!' comes to mind, since it looks almost exactly like a '|' in most fonts. '[' or ']' are other possibilities. Well, ! is pretty common in text, and [ and ] are already used for links. However, the advantage is that by default a '!' cell separator could indicate colspan=2, which would likely be the most common case. So, for colspan=2, no additional pollution of the text would be required. E.g., | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI | ---+--+--+--+--+--+--+--+--+--+ 1 | A1 | B1 ! C1 and D1 | E1 ! F1 and G1 | H1 | I1 | 2 | A2 | B2 | C1 ! D2 and E2 | F2 ! G2 and H2 | I1 | That's not very intuitive to me. Where a colspan greater than 2 is required, metadata must unfortunately be introduced. For this I would like to suggest two alternatives; The first suggestion is similar to David's proposal except that it uses a number of underscores to indicate of the number of columns a cell should span, such that colspan = number of underscores +2. In the most common case, colspan=2, no underscores are required. Colspan=3 requires one underscore, colspan=4 requires two underscores, and so on. 3 == 1, 4 == 2? Ick. If I *must* use metadata characters, then I prefer underscores because they at least look like part of the table
Re: More continuing text for tables
I can't say that I find this proposal to be perfect, but to me this was one of the more compelling emails in this thread. I have been having my own internal conversation about how to rewrite the MMD table syntax. My personal goals were to find a way to minimize the markup, make it more readable/less distracting, and hopefully easier to generate. I started thinking seriously about how to rewrite the table syntax after reading about [elastic tabstops](http://nickgravgaard.com/elastictabstops/). To me, these seemed to be the best way to implement tabs within text documents. Then, it occurred to me that the only time I use tabs in MMD documents is at the beginning of a line, to indicate code blocks, or to indent lists. I never use tabs within a line. Yet tabs are inherently what I want to use to align columns of text in tables. So I started looking into using tabs to separate columns within a table (i.e. replacing the | in the current MMD syntax). If you used spaces before the tab, you could ensure that each row had the same column-widths (for sure with monospace font, and fairly tolerant for some variation with other fonts, but definitely not perfect). If your editor used elastic tabstops, the plain text table would look right, and it would be easily converted to an XHTML table. It doesn't solve the colspan or rowspan issue. My personal thoughts are: * I like the idea of one colspan per row - more than that, and maybe you should just use HTML. This would allow a simpler syntax. * I am increasingly unconvinced that I should worry about rowspans, and require HTML for that. * Every editor should support a standardized approach to elastic tabstops. Too bad I can't make this happen. Keeping in mind that my own goal for MMD is to provide an easy to write/ easy to read syntax for the 80-90% of tables that people write, at the expense of requiring HTML for the other group of complicate tables out there, I think there is hope for a table syntax built (almost?) entirely out of whitespace markers. Thoughts? F- Simon Bull wrote: Okay, thanks for your input, David. Tables with lots of narrow columns are not so rare they can be dismissed; they are useful for matrices of numbers, for example. How about an (entirely optional) addition to the existing multimarkdown pipe syntax, specifically for cells which span many cols? A number followed immediately by a pipe would be taken as the colspan. So this; | This cell spans 7 cols, and has less spa ||| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | would be exactly equivalent to this; | This cell spans 7 cols, and has more space 7| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | It contains 1 ugly metadata character, true. It is a matter of personal taste as to whether you find 6 additional pipes or 1 digit more intrusive, so why not provide authors with the choice? The advantage of the digit meta-character, of course, is the additional space in the cell to write content. The real problem is that *neither* of these options is entirely natural to either the author or the reader. Thinking some more, I realise that neither metadata option is required at all to parse a table row correctly when there is only a single colspan cell in a row _if_ we have a distinct cell-delimiter which denotes a colspanning cell. -- Fletcher T. Penney fletc...@fletcherpenney.net Every so often, I like to go to the window, look up, and smile for a satellite picture. - Steven Wright smime.p7s Description: S/MIME Cryptographic Signature ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Tue, Jun 23, 2009 at 2:38 PM, Michel Fortinmichel.for...@michelf.com wrote: [snip] Are 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: [snip] And here's what I believe you meant: [snip] Which makes me believe my syntax above using explicit line separators may be better, even though it's much more verbose. Wow, I made the exact same mistake, except that I never caught on to what was really indented. In any event, the more verbose syntax proposed by Michael seems like the only reasonable alternative to me as well. That said, I am leaning more toward the opinion that anything more complex that can already be done should be left to raw html. But I've already explained my position on that before. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
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 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Jun 23, 2009, at 11:38 AM, Michel Fortin wrote: 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. Yes, Simon's was not quite right. It should be: |Col A| Col B | Col C +-+--+- | A1 |B1|C1 | a2 contains | b2 | c2 : some long : b2 : c2 : interesting :b2:c2 : commentary : B2 : C2 | A3 |B3|C3 See also pgsql. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
My apologies, I didn't read David's post correctly. After looking at it more closely, I agree with the previous posts; a leading pipe followed vertically by trailing colons is much better than the other way around, so it should have looked like this: Col A| Col B | Col C -+--+- A1 |B1|C1 a2 contains | b2 | c2 some long : b2 : c2 interesting :b2:c2 commentary : B2 : C2 A3 |B3|C3 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. 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. Regarding David's [related proposal][] for the use of tildes '~' for definition lists, I was also going to suggest adding tildes to support definition lists within tables, but I backed off from that in my original post so as not to cloud the central issue; continued text in tables. 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. I will have to have a look at multimarkdown too :) Thanks to all who replied, Simon [related proposal]: http://justatheory.com/computers/markup/modest-markdown-proposal.html On Wed, Jun 24, 2009 at 7:04 AM, David E. Wheeler da...@kineticode.comwrote: On Jun 23, 2009, at 11:38 AM, Michel Fortin wrote: 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. Yes, Simon's was not quite right. It should be: |Col A| Col B | Col C +-+--+- | A1 |B1|C1 | a2 contains | b2 | c2 : some long : b2 : c2 : interesting :b2:c2 : commentary : B2 : C2 | A3 |B3|C3 See also pgsql. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Tue, Jun 23, 2009 at 9:45 PM, Waylan Limbergway...@gmail.com wrote: [snip] colon. In fact, it would seem reasonable to expect that the very implementations which correctly support definition lists (using colons) would be the first to implement any new alternate table syntax, whether it uses colons or not. Sorry, that was supposed to say ...which *currently* support definition lists... Apologies for any confusion my fat fingers may have caused. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
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 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Jun 23, 2009, at 6:45 PM, Waylan Limberg wrote: Actually, PHP Markdown Extra [1], Python-Markdown [2], and Pandoc [3] all support definition lists using the colon as well. And that's only the ones I'm familiar with. There may be others. The point is, I think this is an established enough syntax used by enough people who have written enough documents, that it would be a little to painful to change now. I actually submitted a patch to MultiMarkdown to allow ~ as an alternative, for backwards compatibility. However, I don't believe your proposal mitigates Simon's concern regarding overuse of the colon. In fact, it would seem reasonable to expect that the very implementations which correctly support definition lists (using colons) would be the first to implement any new alternate table syntax, whether it uses colons or not. If the tilde were to be formally adopted by core markdown, the colon would not be overused for this purpose. And I'm going on psql as prior art in suggesting the colon for continued lines. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
