Inline svglite SVGs in gt tables lose styles during Quarto HTML table processing

[cderv]

When gt tables containing inline SVG plots (from gtExtras functions like `gt_plt_dist()`, `gt_plt_sparkline()`, etc.) are rendered in Quarto HTML output, the density/sparkline plots get black backgrounds.

Cause

svglite embeds a `<style>` block inside each SVG's `` that sets `.svglite rect { fill: none }`. Quarto's HTML table processing passes the `

...</table>` HTML through Pandoc's HTML parser (`pandoc.read()`), which drops these `<style>` tags. Without the style rule, SVG rects revert to the spec default `fill: black`.

gt's own CSS (the `<style>#id table { ... }` block) survives because it sits outside the `

` element in the wrapper `

`. The svglite styles are inside `

` cells, so they get processed and lost. Details and evidence in the Quarto issue: quarto-dev/quarto-cli#14285 Workarounds `html-table-processing: none` at document or cell level in Quarto `tab_options(quarto.disable_processing = TRUE)` on the gt table Possible gt-side improvements When a gt table contains inline SVGs with `<style>` tags (e.g. from svglite), automatically set `data-quarto-disable-processing="true"` on the ` ` element. The attribute is already emitted (currently `"false"`) — this would just flip it when SVGs are present. Base64-encode inline SVGs as `` instead of embedding raw SVG markup. This makes the SVG opaque to any HTML parser and immune to style stripping. It would also avoid potential CSS conflicts between the page stylesheet and SVG internals. Move the svglite CSS rules from inside the SVG `` to gt's main `<style>` block (which lives outside ` ` and survives processing). This would require collecting the rules from all SVGs and deduplicating them. Reprex https://github.com/topepo/quarto-gt-reprex Any gt table using `gtExtras::gt_plt_dist()` rendered in Quarto HTML shows the issue. Reported with Quarto 1.9.32, gt 1.3.0, gtExtras 0.6.2.