`<figcaption>` not inheriting layout of figure in HTML.

[batpigandme]

Bug description

Currently, the <figcaption> of an image/figure with a layout class (e.g. column-body-outset) is not having that same class applied.

Steps to reproduce

Here's a GitHub repo with a reproducible example (the index.qmd file): https://github.com/batpigandme/quarto-figcap-demo.

The rendered site is https://mara.quarto.pub/quarto-figcap-demo/.

Expected behavior

I would expect that the <figcaption> would have the same layout as the figure itself (i.e. what happens when I apply .column-body-outset to <figcaption>, as seen below.

Barring that, I would expect the layout in the RStudio Visual Editor to somehow reflect that the caption is not inside of the parent div with the layout class applied (obviously this would be a different issue in that repo).

Actual behavior

.column-body-outset is applied only to the<img>, and not the <figcaption>.

Your environment

• RStudio IDE: 2024.04.0-daily+320 -OS: Mac Ventura 13.6.3

Quarto check output

Quarto 99.9.9
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.1.11: OK
      Dart Sass version 1.69.5: OK
      Deno version 1.37.2: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 99.9.9
      Path: /Users/maraaverick/quarto-cli/package/dist/bin

Check file:///Users/maraaverick/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/maraaverick/Library/TinyTeX/bin/universal-darwin
      Version: 2022

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

[✓] Checking Python 3 installation....OK
      Version: 3.8.11 (Conda)
      Path: /opt/homebrew/Caskroom/miniconda/base/bin/python
      Jupyter: 5.3.0
      Kernels: julia-1.8, python3

(-) Checking Jupyter engine render....Unable to load extension: pydevd_plugins.extensions.types.pydevd_plugin_pandas_types
(|) Checking Jupyter engine render....Unable to load extension: pydevd_plugins.extensions.types.pydevd_plugin_pandas_types
[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.2.3
      Path: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources
      LibPaths:
        - /Users/maraaverick/Library/R/arm64/4.2/library
        - /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library
      knitr: 1.45
      rmarkdown: 2.25.3

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

[batpigandme]

I just checked an older deploy of the same page on which I had this issue (see here, also in screenshot below), and it appears that the entire figure was in a parent <div.column-body-outset>, which I actually think makes more sense in terms of the syntax being used.

Unfortunately, I didn't record what Quarto version that used (it could be well over a year ago).

[cscheid]

Hm. We did change the HTML intentionally. We document it here: https://quarto.org/docs/prerelease/1.4/crossref.html#changes-in-html-output

But I think what you're describing makes sense, and we just didn't realize the consequence. We needed to change that in order for our DOM to support the different crossref use cases that are possible in 1.4.

It's not really a regression, but I think we need to improve this.

[batpigandme]

Thanks for the clarification and pointer to the docs, @cscheid (sorry I missed that before filing this).

I agree, it's definitely not a clear regression,. I played around with some more examples and added them to the GH repo and page I linked to in the issue.

There are definitely a couple instances where it looks “off” to me—namely when you have images near each other where the caption is clearly aligned to the left of one and not the other (see screenshots below)—but they're admittedly edge cases, and it's not that off looking (it's obvious enough to the eye that the captions are basically aligned to the body text).

[cscheid]

Thanks - these examples are super helpful for us.

[dragonstyle]

If we end up adapting the behavior, I think we'll have to make this configurable. Depending upon how figure captions are used, it will often make sense for the captions to follow the body column (for example, in an academic article with narrative and figures which themselves have long and meaningful captions) - it is often very difficult to read long captions that have very long line lengths, so constraining to the body is actually a feature in these cases. I think these are likely the most common cases (at least in our current thinking), so may want to consider some way to specifically set those caption locations / columns.

[batpigandme]

Point well made (and taken), Charles. Realistically, I can't imagine wanting the caption to be longer than the body column, and I hadn't considered what it would look like for a caption with long text. I tested (and added to the example repo/page) a case where I'd wan't the <figcaption> to follow the image layout (I had two grid columns inside of a .column-page), and those work just fine (since the column-page div isn't the direct parent of the images). Given that, I imagine it wouldn't be that hard to hack around the default figcaption layout as is. ~So, I think it's safely low priority! 😊~

[OrenBochman]

It seems like a high impact issue please give it more immediate attention.

Hi, I have a similar issue with caption of basic image in HTML.

Almost 95% of images in my quarto are tucked in the margin and make use of expansion via a lightbox filter.

![a caption](file_name.png){.column-margin}

Since upgrading to 1.4, the caption for these appear in the body column while, the image is now the margin.

Right now, my workaround is to fencing new images with a div, ie:

::: column-margin
![a caption](file_name.png){.column-margin}
:::

however, there is no simple way to automate this as existing images may be in divs or in

elements. and some images have extra attributes in the {} component.

This is a big headache - since there are thousands of links like this.... e.g. screen caps from many lectures. The web standards mandates using captions for SEO but also to support screen readers for people with disablilites.

I suggest updating the priority as this is impacting anyone using a captioned image as part of the marginellia and is breaking layout after upgrading to version 1.4.

Note: I recently reviewed 5+ blog post by users including @batpigandme, instructing on migration of blogs etc. to quarto and pretty many are using the margin one way or another.

p.s. any css based workarounds would be welcome! - the minimal example by @cscheid in the docs is a starting point but after a consult with an AI I don't see how this can be fixed with CSS hack.

also my code looked quite different from the simple example linked above.

[batpigandme]

Hey @OrenBochman,

I just added an example with the basic syntax (i.e. no special surrounding div) to the demo page I made (source code, live demo), and it's possible this has already been fixed in the development version (which is what I use on my machine).

Do you know if this only happens with the lightbox feature?

P.S. Struck my comment re. priority—obviously I haven't gone through all the use cases, and thought it was kind of a niche thing, since I hadn't seen anyone else post about it. 🙂

Update Added an example that uses .lightbox to the demo, and the figcaption location seems fine (though the layout of the figures is overlapping in the version on quarto-pubs, but not locally—I think that's unrelated).

[cscheid]

It seems like a high impact issue please give it more immediate attention.

@OrenBochman I just want to make it clear that we decide what to work on based on what we perceive is most important. We were working on it over the weekend. Please be more considerate in your wording in the future.

[dragonstyle]

I was able to reproduce this when using lightbox + margin captions. I'm going to go ahead and open a separate issue to track this as it isn't the same issue as this.

[dragonstyle]

https://github.com/quarto-dev/quarto-cli/issues/8697

[OrenBochman]

@OrenBochman I just want to make it clear that we decide what to work on based on what we perceive is most important. We were working on it over the weekend. Please be more considerate in your wording in the future.

I'd like to apologize to everyone, as my note was out of line.
I will try to do better going forward.

Also, I understand the code in the screenshot better and realize that this is a more nuanced issue and not the bug of the basic :lady_beetle: I thought it was.

I salute :vulcan_salute: the work you are doing on Quarto, thanks for the assistance!

[OrenBochman]

Hey @OrenBochman,

I just added an example with the basic syntax (i.e. no special surrounding div) to the demo page I made (source code, live demo), and it's possible this has already been fixed in the development version (which is what I use on my machine).

Do you know if this only happens with the lightbox feature?

P.S. Struck my comment re. priority—obviously I haven't gone through all the use cases, and thought it was kind of a niche thing, since I hadn't seen anyone else post about it. 🙂

Update Added an example that uses .lightbox to the demo, and the figcaption location seems fine (though the layout of the figures is overlapping in the version on quarto-pubs, but not locally—I think that's unrelated).

last I checked @dragonstyle opened a new bug and fixed it (by promoting the collum-margin css selector to the figure.) I wouldn't mind using a nightly build as I have couple of fixed issues that are bothersome to work with.

[dragonstyle]

We have fresh pre-release builds that include the fix (any of the newer 1.5 builds will have it- there is a fresh one as of this morning).

https://quarto.org/docs/download/

It will also be in our next 1.4 patch release, which is imminent, but not 100% sure when that will arrive.