Custom listing appears to break with certain kinds of HTML

[jimjam-slam]

Bug description

Consider a basic Quarto site, with _quarto.yml:

project:
  type: website

And index.qmd:

---
title: "Hello"
listing:
  template: listing.ejs
  contents:
    - title: Post A
      path: a
    - title: Post B
      path: b
    - title: Post C
      path: c
    - title: Post D
      path: d
---

If I add a listing.ejs based on the example in the docs, it works fine. Here I've modified it to wrap each item.title in a p.test-class:

<% for (const item of items) { %>
  <a href="<%- item.path %>">
    <p class="test-class">
      <%= item.title %>
    </p>
  </a>
<% } %>

But if I change the p to div, the listing breaks, rendering the contents of the for loop as a code block:

<% for (const item of items) { %>
  <a href="<%- item.path %>">
    <div class="test-class">
      <%= item.title %>
    </div>
  </a>
<% } %>

If I use an online tool to validate the EJS, it seems fine.

Your environment

• IDE: VSCode 1.96.2
• macOS 15.2

Quarto check output

quarto check
Quarto 99.9.9
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.2.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.41.0: OK
      Typst version 0.11.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 99.9.9
      commit: 86968494bcc34974e275c8b32ff9fb72fb130c93
      Path: /Users/rensa/code/tools/quarto-cli/package/dist/bin

Check file:///Users/rensa/code/tools/quarto-cli/src/resources/vendor/deno-land/x/puppeteer@9-0-2/mod.ts
[✓] Checking tools....................OK
      TinyTeX: (external install)
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/rensa/Library/TinyTeX/bin/universal-darwin
      Version: 2021

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.11.5
      Path: /opt/homebrew/opt/[email protected]/bin/python3.11
      Jupyter: (None)

      Jupyter is not available in this Python installation.
      Install with python3 -m pip install jupyter

[✓] Checking R installation...........OK
      Version: 4.4.1
      Path: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources
      LibPaths:
        - /Users/rensa/Library/R/arm64/4.4/library
        - /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library
      knitr: 1.48
      rmarkdown: 2.28

[✓] Checking Knitr engine render......OK

[jimjam-slam]

In the real version I wrote where I discovered this, I also had the same problems with divs outside the for loop:

<div>
  <div>
    <% for (const item of items) { %>
      <a href="<%- item.path %>" class="my-item">
        <p>
          <%= item.title %>
        </p>
      </a>
    <% } %>
  </div>
</div>

[jimjam-slam]

For there most part I'm able too substitute other elements for divs, but in this example the opening and closing p tags actually get both read as incomplete, leading to them being converted into two empty p elements instead of a single p that wraps the other content:

<p class="test-listing-main">
  <ul class="test-listing-container">
    <% for (const item of items) { %>
      <li class="test-listing-item">
        <a href="<%- item.path %>"></a>
      </li>
    <% } %>
  </ul>
</p>

Rendered HTML (I've run in through a formatter to make the indentation clearer):

<div
  id="listing-projects-oss"
  class="quarto-listing quarto-listing-container-custom"
>
  <p class="test-listing-main"></p>
  <ul class="test-listing-container">
    <li class="test-listing-item">
      <a href="../projects/oss/unswthesisdown/index.html"></a>
    </li>
    <li class="test-listing-item">
      <a href="../projects/oss/stickylabeller/index.html"></a>
    </li>
    <li class="test-listing-item">
      <a href="../projects/oss/collateral/index.html"></a>
    </li>
    <li class="test-listing-item">
      <a href="../projects/oss/columnflow/index.html"></a>
    </li>
    <li class="test-listing-item">
      <a href="../projects/oss/sverto/index.html"></a>
    </li>
    <li class="test-listing-item">
      <a href="../projects/oss/ggflags/index.html"></a>
    </li>
    <li class="test-listing-item">
      <a href="../projects/oss/closeread/index.html"></a>
    </li>
    <li class="test-listing-item">
      <a href="../projects/oss/weatheroz/index.html"></a>
    </li>
  </ul>
  <p></p>
  <div class="listing-no-matching d-none">No matching items</div>
</div>

[jimjam-slam]

Surprisingly this does work as expected! Perhaps I was too hasty in saying the problem is with divs in particular:

<div class="test-listing-main">
  <ul class="test-listing-container">
    <% for (const item of items) { %>
      <li class="test-listing-item">
        <a href="<%- item.path %>"></a>
      </li>
    <% } %>
  </ul>
</div>

[mcanouil]

Are you using raw code block?

https://quarto.org/docs/authoring/markdown-basics.html#raw-content

[jimjam-slam]

@mcanouil Are raw blocks required inside of EJS templates?

[mcanouil]

EJS files are read as Markdown which can explain your parsing issue because Pandoc needs to guess it's HTML.

[jimjam-slam]

Oh, wow! Do you know how I can mark section of the EJS file as raw HTML? Or should I just write the whole thing as Pandoc Markdown and use fenced divs?

[mcanouil]

Both as not all can be (easily) written as Markdown and see the link I shared previously.

[jimjam-slam]

Thanks @mcanouil, I'll give it a crack!

[mcanouil]

Beware that any EJS variables inside raw block won't be read as Markdown thus be evaluated.

(That's currently an issue with 1.7.5 listings where raw blocks were added to avoid Pandoc memory issues likely caused by its way to try to parse HTML)

[jimjam-slam]

I've wrapped the contents of the EJS file in a raw HTML block and it seems to work quite well now 😊 Thanks @mcanouil!

[jimjam-slam]

I wonder if the Custom Listing documentation should be updated to mention that EJS templates are processed as Markdown. Markdown isn't mentioned at all, and the example given only uses HTML. Statements like these also heavily imply that we should expect the template to emit HTML rather than Markdown:

This custom display can generate any HTML...

... you create an EJS template that will be used to generate the HTML for a set of items that are passed to the template. EJS templates allow you to generate HTML using plain javascript...