There's a PR open here which suggests allowing tables with all empty header cells be rendered without the header all together.
The proposed syntax is something like:
Non-empty (should include header filled with empty space – current result):
| | |
| -------- | -------- |
| cell 1.1 | cell 1.2 |
| cell 2.1 | cell 2.2 |
Empty (render without header):
|||
| -------- | -------- |
| cell 1.1 | cell 1.2 |
| cell 2.1 | cell 2.2 |
I wondered weather there was any interest in formalising this as part of the spec (in the case that no header content is desired, allowing an option for rendering without it probably looks a little better than having a header full of empty space).
Perhaps even an alternative, as an intuative variant on https://github.github.com/gfm/#example-198
| abc | def |
| --- | --- |
Which, as part of the current spec, renders to
<table>
<thead>
<tr>
<th>abc</th>
<th>def</th>
</tr>
</thead></table>
We could have a no header variant, like:
| --- | --- |
| abc | def |
Which could be defined to render to:
<table>
<tbody>
<tr>
<td>abc</td>
<td>def</td>
</tr></tbody></table>
Obviously it would require a blank line before if content prior could be interpreted as inlines, but I don't think that's any worse than the empty table body in existing syntax requiring a blank line after.
There's a PR open here which suggests allowing tables with all empty header cells be rendered without the header all together.
The proposed syntax is something like:
Non-empty (should include header filled with empty space – current result):
Empty (render without header):
I wondered weather there was any interest in formalising this as part of the spec (in the case that no header content is desired, allowing an option for rendering without it probably looks a little better than having a header full of empty space).
Perhaps even an alternative, as an intuative variant on https://github.github.com/gfm/#example-198
Which, as part of the current spec, renders to
We could have a no header variant, like:
Which could be defined to render to:
Obviously it would require a blank line before if content prior could be interpreted as inlines, but I don't think that's any worse than the empty table body in existing syntax requiring a blank line after.