RFC Spec extension for *tables*: Syntax and transformation rules

Extensions
8
  1. Back-tracking is hard for both, human and computer parsers. The type of block should be determined within the first two lines.
  2. Making leading pipe mandatory in most cases is a direct consequence of issue 1.
  3. Trailing pipe is similar to trailing hash signs in headings. I just wanted to make clear that although the reasoning is different, they should still parallel leading pipes.
  4. I’m not a big fan of hash-equals, but it is commonly used in adhoc email tables, which was the major source for original Markdown. The note on corner symbols was rather informative, not a proposal to include them.
  5. Your proposal makes multi-row headers impossible. That’s bad.
  6. HTML does support multiple <tbody> elements per table, and the scope attribute for headers has a rowgroup value. Latex’s longtable even allows multiple headers and footers, i.e. one on each page for tables spanning multiple pages.
  7. I meant that in HTML you can have 3 explicit <td> in one row, 2 in the one before and 4 in the one after, but in LaTeX when you specify 3 columns you need to have 2 ampersands & and a line end \\. That’s just something to consider when deciding whether each line of a table must have the same number of pipes |.
  8. My point was , you’re using the heading characters = and -, but “rule” (as in <hr>) terminology. I’ve already raised the topic of harmonization in a thread of its own. It’s mostly a matter of consistency.
  9. This follows from issues 8 and 11. I’ll explain it further down. Your plus sign + for colspan idea seems worthwhile to explore further.
  10. See this example for what I meant, I’m not sure why Maruku sees just one column, though. When I started to write my unfinished CM table syntax proposal, I tried to reuse horizontal rules, thinking that existing implementations already supported that.
  11. No, you’re creating a straw man: comma, period, apostrophe, backtick and even hash sign are completely don’t apply here at all. **** and ____ are equivalent to ---- in generating horizontal rules outside “column blocks”. Normal CM text is written in an implicit 1-column block. Pipes would constitute explicit column blocks. An explicit 1-column block could be treated in a special way (like Pandoc does). I was arguing that the result of “horizontal rules” would be slightly different in explicit column blocks, i.e. </tr><tr> instead of <hr> in HTML.
  12. Row header cell in HTML: <tbody>…<tr><th scope=row>row header<td>normal content</tr>
  13. Try foo | bar
  14. Syntax for a caption (i.e. table heading) is missing. (I forgot to mention that before.)

Code examples for 2. (optional leading pipe)

Table started and ended with table rule:

---|---
 A | B
---|---

Table with unambiguous number of columns from first row:

| A | B
  C | D

Code examples for 9. (possible different handling of = and - table rules)

The HTML output below only shows the contents of the <tbody>, the header is always the same:

<table><thead><tr><th> A <th> B </thead><tbody>
<!-- … -->
</tbody></table>

| A | B |
|---|---|
| C | D |
| E | F |

<tr><td> C <td> D
<tr><td> E <td> F

Test implementations

| A | B |
|===|===|
| C | D |
| E | F |

<tr><td> C E <td> D F

or maybe

<tr><td> C<br>E <td> D<br>F

Test implementations

| A | B |
|===|===|
| C | D |
|---|---|
| G | H |

<tr><td> C <td> D
<tr><td> G <td> H

Test implementations

| A | B |
|===|===|
| C | D |
|---| F |
| G | H |

<tr><td> C <td rowspan=2> D F H
<tr><td> G

or maybe

<tr><td> C <td rowspan=2> D<br>F<br>H
<tr><td> G

Test implementations