Raw HTML tables get an equal-width <colgroup> when any cell contains block content, overriding cell widths
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 52/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- javascript
- 領域
- backend
研究方向
Start with src/resources/filters/normalize/astpipeline.lua, where the issue says Quarto reads raw HTML tables with pandoc.read(tableHtml, "html+raw_html"); then trace how the resulting table is written back out. Compare tables with and without declared <col> widths, especially when a cell contains block content. Done means tables without author-specified column widths no longer gain equal-width columns, while declared widths remain intact; the issue suggests resetting widths to ColWidthDefault.
由索引模型根據 Issue 內容生成。
描述
I have:
- searched the issue tracker for similar issues
- installed the latest version of Quarto CLI
- formatted my issue following the Bug Reports guide
Bug description
When HTML table processing parses a raw HTML table that has no <col> widths, and any cell contains block content (e.g. a <div>), every column gets an equal width in the output. Widths set on the cells are then overridden.
The widths come from Pandoc's HTML reader. With no <col> widths, it leaves the widths unset when every cell is simple, and otherwise assigns 1 / ncols to each column (normalizeColWidths). Quarto reads the table with pandoc.read(tableHtml, "html+raw_html") (astpipeline.lua) and writes it back out, so those widths become a <colgroup>.
This is how it shows up for R users: kableExtra's add_header_above() wraps each group label in a <div>, so column_spec(width = ...) stops working as soon as a spanning header is added (rstudio/rstudio#19321, haozhu233/kableExtra#915). rmarkdown::render() passes the HTML through untouched, so the same table is fine there.
Steps to reproduce
---
format: html
---
```{=html}
<table>
<thead>
<tr><th>a</th><th><div>b</div></th><th>c</th></tr>
</thead>
<tbody>
<tr><td>1</td><td style="width: 5cm">2</td><td>3</td></tr>
</tbody>
</table>
```
The original kableExtra example:
---
format: html
---
```{r}
library(kableExtra)
kable(mtcars[1:5, 1:4], format = "html") |>
add_header_above(c(" " = 1, "Group 1" = 2, "Group 2" = 2)) |>
column_spec(2:3, width = "5cm")
```
Actual behavior
<colgroup>
<col style="width: 33%">
<col style="width: 33%">
<col style="width: 33%">
</colgroup>
In the kableExtra example, the <colgroup> has five width: 20% columns, and Chrome draws every column at 160px. The width: 5cm (about 189px) on columns 2 and 3 is ignored.
Expected behavior
No <colgroup>, the same as when the <div> is removed from the header cell, so the widths on the cells apply. In the kableExtra example with html-table-processing: none, there is no <colgroup> and columns 2 and 3 come out at 189px (data-quarto-disable-processing="true" also drops the <colgroup>). Setting tbl-colwidths: false does not help.
A possible fix: after pandoc.read(), reset the column widths to ColWidthDefault when the source table declared no <col> widths, since the equal widths were not specified by the author.
I haven't run the 1.11 pre-release, but the parsing code is unchanged on main, main still pins Pandoc 3.10, and Pandoc 3.12.1's HTML reader behaves the same way.
Your environment
- Quarto 1.10.19 (the copy bundled with RStudio), run from the command line; same result rendering from RStudio
- macOS 27.0.1 (the original report is on macOS Sequoia 15.8.1)
- kableExtra 1.4.1, R 4.6.1
Quarto check output
Quarto 1.10.19
[✓] Checking environment information...
[✓] Checking versions of quarto binary dependencies...
Pandoc version 3.10.0: OK
Dart Sass version 1.101.0: OK
Deno version 2.7.14: OK
Typst version 0.15.1: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
Version: 1.10.19
Path: /Applications/RStudio.app/Contents/Resources/app/quarto/bin
[✓] Checking basic markdown render....OK
[✓] Checking R installation...........OK
Version: 4.6.1
Path: /Library/Frameworks/R.framework/Resources
knitr: 1.52
rmarkdown: 2.32
[✓] Checking Knitr engine render......OK
- 主要語言
- JavaScript
- 星號
- 6.1k
- 分支
- 478
- 平均合併
- 17 小時 7 分鐘
- 30 天內合併 PR
- 112
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
quarto-dev/quarto-cli 的其他 Issue
-
enhancement websites
難度 2/5 1-3 小時 新手友好度 78/100
quarto-dev/quarto-cli#15255 · 1 則留言 ·
維護者通常 1 天內回覆
-
Website announcement dismiss control cannot be reached or used with a keyboard可能已有人在做 @Xander-AJ 今天認領。 未關閉accessibility bug websites
難度 1/5 1-3 小時 新手友好度 88/100
quarto-dev/quarto-cli#15235 ·
維護者通常 1 天內回覆
-
quarto.json.decode does not raise on invalid JSON, so pcall cannot catch it可能已有人在做 @sogav21 於 2 天前認領。 未關閉bug lua
難度 2/5 1-3 小時 新手友好度 84/100
quarto-dev/quarto-cli#15226 ·
維護者通常 1 天內回覆
-
arrow-dark gives region markers a light band that fails contrast可能已有人在做 @vav7 於 1 天前認領。 未關閉accessibility bug themes
難度 1/5 1 小時以內 新手友好度 88/100
quarto-dev/quarto-cli#15222 ·
維護者通常 1 天內回覆
-
bug code-annotation
難度 2/5 1-3 小時 新手友好度 76/100
quarto-dev/quarto-cli#15215 ·
維護者通常 1 天內回覆
查看 quarto-dev/quarto-cli 的全部 Issue
相似的 Issue
-
good first issue
難度 2/5 3-5 天 新手友好度 62/100
paipai1999/POS-system#3 ·
-
good first issue
難度 2/5 1-3 小時 新手友好度 85/100
r-afael/better-yt-recommendations#36 ·
維護者通常 1 天內回覆
-
needs-triage
難度 2/5 1-3 小時 新手友好度 66/100
microsoft/playwright#43875 · 1 則留言 ·
維護者通常 1 天內回覆
-
cli good first issue
難度 2/5 1-3 小時 新手友好度 85/100
維護者通常 1 天內回覆
-
Run the dependency drift check可能已有人在做 @spaceninja 今天認領。 未關閉
難度 1/5 1 小時以內 新手友好度 82/100
cloudfour/stylelint-config-cloudfour#683 ·
維護者通常 1 天內回覆