Using tab_source_note and tab_footnote together in quarto distorts table

[werkstattcodes]

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

[rich-iannone]

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.

[werkstattcodes]

Many thanks for all your efforts. It's a wonderful package.

[rich-iannone]

@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.