Hugo Goldmark table data colspan

support
1

I am trying to display a table with some data spanning columns, and I think I have stumbled upon a bug.

Am I doing something wrong?

In a content file (foo.md) I have a table defined as such [note discourse is displaying slashes, but they are indeed vertical pipes]:

|Heading A|Heading B|Heading C|Heading D|Heading E|
|---|---|---|---|---|
|<td colspan="3">First|Next|

Expected:

A table row with “First” bridging columns 1-3, and Next appearing in column 4.

Received:

A table row with “First” bridging columns 2-4, and Next appearing in column 5.

Heading A Heading B Heading C Heading D Heading E
First Next 
<table>
<thead>
<tr>
<th>Heading A</th>
<th>Heading B</th>
<th>Heading C</th>
<th>Heading D</th>
<th>Heading E</th>
</tr>
</thead>
<tbody>
<tr>
<td></td><td colspan="3">First</td>
<td>Next</td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

Analysis:

It appears somewhere in the rendering of the Goldmark table, something is broken. The use of the <td colspan> appears to close the current td element before it is implemented, resulting in a table that is always skewed one column to the right.

Unfortunately, I do not have the means to track the bug down to determine whether it is Hugo, Go, the Goldmark table extension, whatever…

Ideas? Or is this indeed a bug?

Environment

hugo env:
hugo v0.111.3-5d4eb5154e1fed125ca8e9b5a0315c4180dab192+extended windows/amd64 BuildDate=2023-03-12T11:40:50Z VendorInfo=gohugoio
GOOS="windows"
GOARCH="amd64"
GOVERSION="go1.20.1"
github.com/sass/libsass="3.6.5"
github.com/webmproject/libwebp="v1.2.4"

and in case it matters, my config.toml contains:

[markup]
[markup.goldmark]
[markup.goldmark.renderer]
unsafe = true
2

Goldmark renders markdown tables using its built-in table extension, which complies with the GitHub Flavored Markdown (GFM) specification for tables. The GFM specification has no provision for col/row span.

Define the table using HTML.

3

I may be reading it wrong, however the built-in table extension does have support for colspan, for both header and row values.

That is how I tested the table colspan in my “sample” above. It appears they went “beyond” the spec…

In light of this, I’ll raise the bug report there and see what comes of it.

4

The attribute filter has nothing to do with parsing. If you can create a markdown table in a GithHub issue with functional colspans, then you have proven that GFM allows it.

5

That’s the thing… From my initial report above,

I am able to paste that into a GitHub issue, and it shows the same problem. NOTE: They do respect the colspan!

image

image

HOWEVER,
After having written all that, I think I have found out why it partially works. In the specs, it appears ANYTHING enclosed in < > will be parsed as raw HTML. So by putting |<td colspan=3>First, it was interpreted as: | starts a <td>, then because of the raw html it closed the old </td> and opened a new one with the colspan attribute, and continued parsing on its merry way.

Interesting that the specs don’t support the colspan, but the implementation “almost” does… but that’s not a Hugo issue.