Re: More continuing text for tables
On Jun 25, 2009, at 6:30 AM, Sherwood Botsford wrote: 1. Editing with non-elastic tab stops? While Nick's idea is good, the number of editors that support it is small. Editors are a religious issue. I doubt that people will switch editors in order to use MMD tables. And it's not just editors: It's browsers, too. One of the great things about Markdown is that you can display the plain text anywhere and it will just work. Tabs are completely contrary to that, however. Elastic tabs may work as a nice convention in small teams writing source code, but tabs are evil for widely distributed code and documents. 2. I would like to see an option for a non-white character. I've been burned a few times by text processors that convert tabs to spaces. This will also ease the transition if you are changing the spec. +1 3. For row spanning, the simplest syntax that is intuitive to me would be a cell that has a single double-quote character. Effectively saying 'same as above'. I'm not sure that's visually distinctive enough. We really might just have to have row separators when merging rows in a cell. Or just use HTML, like Fletcher said. 4. Tables are one of the biggest reasons for using MMD. The ratio of tag bytes to content bytes can be well over 1. Matching tags is always a pain. Even the clunkiest syntax proposed on this list has more merit than html table tags. My take: It aint broke. Resist fixing it. I agree. Most of the suggestions I've made were evolutions on the MMD syntax, and an attempt to eliminate non-semantic hinting characters. 1. Continue to support the pipe and multiple pipe syntax. Cells that span more than 3 columns are very rare, and many of these may be done with a title instead, or be broken into multiple tables that are floated inline. +1 2. Use quotes for row span. Or see what cow paths develop. 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 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
1. Editing with non-elastic tab stops? While Nick's idea is good, the number of editors that support it is small. Editors are a religious issue. I doubt that people will switch editors in order to use MMD tables. 2. I would like to see an option for a non-white character. I've been burned a few times by text processors that convert tabs to spaces. This will also ease the transition if you are changing the spec. 3. For row spanning, the simplest syntax that is intuitive to me would be a cell that has a single double-quote character. Effectively saying 'same as above'. 4. Tables are one of the biggest reasons for using MMD. The ratio of tag bytes to content bytes can be well over 1. Matching tags is always a pain. Even the clunkiest syntax proposed on this list has more merit than html table tags. My take: It aint broke. Resist fixing it. 1. Continue to support the pipe and multiple pipe syntax. Cells that span more than 3 columns are very rare, and many of these may be done with a title instead, or be broken into multiple tables that are floated inline. 2. Use quotes for row span. On Wed, Jun 24, 2009 at 8:32 PM, Fletcher T. Penney < fletc...@fletcherpenney.net> wrote: > 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
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
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 wrote: > 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 pr
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
Personally, I would prefer to use exactly one table syntax, so long as it _works_. 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 | 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. I don't mind whether we use the leading or trailing cell-delimiter for this, but in my examples below, I mostly use a leading cell delimiter. The disadvantage of using another type of cell delimiter is that it introduces additional table framework into our text. 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 | 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. 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. 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. 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 [3colspan three [ colspan two [4colspan four 3 | A3 | B3 | C3 | D3 | E3 | F3 | G3 | H3 | I3 would be exactly equivalent to | 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 three3] colspan two ] colspan four 4] 3 | A3 | B3 | C3 | D3 | E3 | F3 | G3 | H3 | I3 | This approach requires fewer metadata characters overall, but I prefer the first suggestion (underscores) because it looks nicer, and reads more easily. Simon On Wed, Jun 24, 2009 at 12:23 PM, David E. Wheeler wrote: > 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 :
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
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 Tue, Jun 23, 2009 at 9:45 PM, Waylan Limberg 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 Tue, Jun 23, 2009 at 5:01 PM, David E. Wheeler wrote: > 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. 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. Of course, if anyone wanted to introduce an alternate syntax using the tilde, they certainly can. 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. [1]: http://www.michelf.com/projects/php-markdown/extra/#def-list [2]: http://www.freewisdom.org/projects/python-markdown/Definition_Lists [3]: http://johnmacfarlane.net/pandoc/README.html#definition-lists -- \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
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 wrote: > 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 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
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 Tue, Jun 23, 2009 at 2:38 PM, Michel Fortin 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
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|C3 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: |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.for...@michelf.com http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
More continuing text for tables
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 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
