Avoid vertical space with backend_show

[rikhuijzer]

Description

When using CairoMakie in Pluto.jl, a lot of whitespace is in some cases shown above and below the Makie images. For example, when plotting

let
  fig = Figure(; size=(1400, 600))
  ax = Axis(fig[1, 1])
  scatter!(ax, Point2f[(100, 300), (200, 400)])
  fig
end

with Makie v0.11.8, the output looks as follows:

The root cause for this seems to be that Makie generates the following HTML:

<img width="1400" height="600" style="object-fit: contain;" src="data:image/png;base64,...">

Here, it makes sense that the width and height are set explicitly because that metadata cannot be set in the base64 encoded image if I'm not mistaken. Next, the object-fit: contain; causes the image to always retain the original aspect ratio by rescaling the image width or height when needed. However, object-fit: contain will not automatically rescale the HTML element width or height when needed. Instead, those remain fixed and the object will be "letterboxed" (more information at the Mozilla docs). In the example image, for example, the height remains 600 even though the image height is rescaled to 291.

This PR suggests to fix that by setting height: auto in the style. This tells the browser that the height of the containing element can be rescaled if needed. I've tested this with Pluto.jl and PlutoStaticHTML.jl and in both cases this will avoid the vertical space.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• Added an entry in NEWS.md (for new features and breaking changes)
• Added or changed relevant sections in the documentation
• Added unit tests for new algorithms, conversion methods, etc.
• Added reference image tests for new plotting functions, recipes, visual options, etc.

[jkrumbiegel]

I'm not really knowledgeable enough about CSS and HTML to know if this is the "right" solution, but if it has a better result in more frontends that's fine with me. I had thought that width and height of the img tag communicated the intended size of the image, but that it could still be scaled depending on its placement in a container div. I had chosen these settings at the time because the VSCode plot pane had some max-width setting or so that squished the image under certain circumstances. If height auto fixes that as well, we might be able to remove the object-fit: contain; because the image should effectively never have a squished size.

[rikhuijzer]

I had thought that width and height of the img tag communicated the intended size of the image, but that it could still be scaled depending on its placement in a container div.

Yes and I think your observation that object-fit: contain; avoids squishing is correct. I have experimented a bit with the settings and it looks like object-fit: contain and height: auto; are both needed. I think the interpretation of this combination should be something along the lines of "with object-fit: contain, the image will be scaled down while retaining the aspect ratio when the width of the containing element becomes smaller than the image width. However, the height will not be scaled, but the image will become letterboxed. With height: auto, the element height is allowed to downsize too."

Below is an example from PlutoStaticHTML.jl. I've tested the patch for Pluto.jl too, but not with VSCode as I don't have that installed.

Example

Here is an example from https://huijzer.xyz/posts/latent/. The width of this page is restricted to 705 px on desktop screens via the franklin-content class. Further down in the CSS hierarchy, images are restricted to width: 100% (so 705 px).

When I change the settings, I see the following (see which settings are enabled/disabled in the bottom of the images).

Figure 1: Squished aspect ratio

Figure 2: Too much vertical space

Figure 3: Correct

[rikhuijzer]

height: auto is also set for Documenter.jl by default in the CSS (example page: https://turinglang.org/MCMCChains.jl/stable/makie/) and in the Makie docs CSS (example page: https://docs.makie.org/stable/reference/plots/barplot/).

[rikhuijzer]

Thanks for updating the CHANGELOG for me and for accepting this patch, @jkrumbiegel 🙂

[jkrumbiegel]

thank you!