Using tab_source_note and tab_footnote together in quarto distorts table
Prework
- [x ] Read and agree to the code of conduct and contributing guidelines.
- [ x] If there is already a relevant issue, whether open or closed, comment on the existing thread instead of posting a new issue.
Description
When using tab_source_note and tab_footnote together in a quarto document, the rendered document shows a broken/distorted table. However, running the code chunks interactively (i.e. not rendering in quarto) returns the correct, intended table.
Reproducible example
I copy here the entire code of the quarto document. Running a reprex in an .r file doesn't reveal the error.
title: "Untitled" format: html
library(tidyverse)
library(gt)
packageVersion("gt")
only source note
mtcars %>%
gt() %>%
tab_source_note(
source_note="this is the source"
)
only footnote
mtcars %>%
gt() %>%
tab_footnote(
footnote="this is the footnote",
locations=cells_column_labels(columns=carb)
)
both: error
mtcars %>%
gt() %>%
tab_source_note(
source_note="this is the source"
) %>%
tab_footnote(
footnote="this is the footnote",
locations=cells_column_labels(columns=carb)
)

Expected result
Table should contain footnote and sourcenote and be rendered correctly in quarto.
Session info
sessionInfo() R version 4.2.3 (2023-03-15 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 19045)
Matrix products: default
locale:
[1] LC_COLLATE=English_Austria.utf8 LC_CTYPE=English_Austria.utf8 LC_MONETARY=English_Austria.utf8 LC_NUMERIC=C
[5] LC_TIME=English_Austria.utf8
attached base packages: [1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached): [1] compiler_4.2.3 tools_4.2.3 rstudioapi_0.14
Sorry for the problem you're facing. We know what the underlying issue is (two tfoot elements which do not pass W3C HTML validation and cannot be parsed by Pandoc 3) and some workarounds are possible right before the fix is in place.
One workaround is to update Quarto to the latest release. I believe there is new code in there that skips parsing of tables if they are determined not to be parsable by Pandoc. I tested with the latest Quarto on my machine and the failing table does appear in the rendered HTML document.
Another workaround involves using tab_options(quarto.disable_processing = TRUE). This will signal to Quarto that the table should not be parsed at all.
We will fix the problem with the rendering so that Pandoc can parse it but, in the meantime, these two workarounds should hopefully get you unstuck.
Many thanks for all your efforts. It's a wonderful package.
@werkstattcodes Thanks! New versions of Quarto will gracefully avoid this issue by automatically not parsing the content if it doesn't pass HTML5 validation. The table will render now without having to do anything on your part. You'll probably get a warning like:
WARNING (.../quarto-cli/src/resources/filters/./normalize/parsehtml.lua:71) Unable to parse table from raw html block: skipping.
But tables with footnotes and source notes will still render in HTML. I am still aiming to fix the underlying issue (so, keeping this open) but the problem isn't as acute as it was when you filed this issue.
I reported initially in
- https://github.com/ddsjoberg/gtsummary/issues/2276#issuecomment-3084450138
for this problem in quarto
- https://github.com/quarto-dev/quarto-cli/discussions/13092
But this is in fact linked to this issue as described above https://github.com/rstudio/gt/issues/1296#issuecomment-1500441514
(two tfoot elements which do not pass W3C HTML validation and cannot be parsed by Pandoc 3)
This prevents rendering gt in Typst output because table can't be parsed.
---
title: "Untitled"
format: typst
editor: visual
keep-typ: true
keep-md: true
---
```{r}
library(gt)
gtcars |>
dplyr::select(mfr, model, msrp) |>
dplyr::slice(1:5) |>
gt() |>
tab_source_note(source_note = "From edmunds.com") |>
tab_footnote(
footnote = "This is a footnote.",
locations = cells_column_labels(columns = msrp)
)
```