conditional-vars — A Quarto extension for variable-based conditional content

[lsbjordao]

Description

I built a Quarto extension that conditionally shows or hides content blocks based on document variables values — filling a gap not covered by Quarto's built-in .when (which is profile-based only).

Features:

• .when-var / .unless-var div classes to show/hide content
• AND logic via multiple attributes
• OR logic via pipe-separated values (type="detailed|summary")
• Numeric comparisons (year=">2020", year="<=2023")
• Mixed .when-var + .unless-var on the same block
• {{< show-vars >}} shortcode to display all active params (useful for debugging)

Repository: https://github.com/lsbjordao/quarto-conditional-vars

[mcanouil]

Thanks!

Few things:

• Using params might be confusing for users as those aren't metadata and are a special case for computation. Especially because you "merge" actual metadata (_variables.yml) into it from YAML. Parameters and metadata are two very different things.
• params is only valid in computation for knitr and Julia engines. Probably worth being explicit about it.
• Have you tried changing the parameters from the command line to check compatibility? https://quarto.org/docs/computations/parameters.html#rendering
• You might want to tell your LLM about the Quarto Lua API for messaging and other operations: https://quarto.org/docs/extensions/lua-api.html

The idea to extend beyond Boolean is a great idea and was requested in the past, mixing params and metadata without proper testing/validation feels unsafe very likely with unexpected behaviours (Parameters not updated in code cells, parameters overridden by merge, no Jupyter engine support, etc.)

[lsbjordao]

Thanks for the feedback!

My mistake! So I've removed confusion around params entirely from the extension design. I've also updated the original post to reflect the new solution.

The extension now reads project-level variables directly from _variables.yml via a Lua filter. It does not interact with computational parameters or execution cells, and works independently of the execution engine (knitr, Jupyter, Julia, Observable).

I also switched warning messages to quarto.log.warning() using the Quarto Lua API and updated the README to clarify the scope and behavior of the extension.

The goal now is simply to complement profile-based .when and .unless by enabling conditional content driven by _variables.yml project variables, without relying on engine-specific features.

Let me know if this direction looks safer and more aligned with Quarto’s intended metadata model.

[mcanouil]

I did not meant to necessarily change "params" if your intent was to account for computational parameters.
You are the creator of this extension, so that's up to you to define the direction.
I was only sharing feedbacks about some aspects tied to Quarto CLI behaviour in case it wasn't accounted for.

[lsbjordao]

I understood the trade-off and decided to keep the scope focused on _variables.yml project variables.

Supporting params would require engine-specific behavior and CLI compatibility considerations, so I decided to keep the scope focused on _variables.yml project variables for a more predictable metadata-driven workflow.