Layouts: Rockfield preview images not filling canvas

[ianstewart]

Chrome and MacOS:

I expected the images to fill the area.

[obenland]

@ianstewart Do you remember which theme you had active when you previewed that? It doesn't look like that's an issue with all themes.

[frontdevde]

Notes on how to reproduce the issue:

This issue appears to occur in the Homepage Template of Rockfield. Note that it's not tied to which theme you have currently selected, it appears with all themes including Rockfield.

So in order to reproduce the issue select the Homepage Template of Rockfield in any theme.

[frontdevde]

Updated initial observation:
The issue appears to be related to the Parallax option on the cover block that's used in this template. The class has-parallax sets the value for the CSS property background-attachment to fixed, which prevents background-size: cover from always ensuring the image covers the whole block.
My initial assumption would thus be that this isn't necessarily a bug of the template but related to the Parallax feature of the Cover block.

Continuing to look into it...

[frontdevde]

Cause of the issue

As initially assumed, the issue is caused by the combination of background-size:cover and background-attachment:fixed. Setting the background-attachment to fixed takes the element out of the positioning context, somewhat similar to how a fixed positioned image would behave. This changes the way that width for background-size:cover is calculated as it's not relative to the element that it's a background image of anymore but the positioning context.

This doesn't surface as an issue as long as the size of the positioning context matches the site of the element with the background image. It surfaces as an issue in template previews because we need to scale the positioning context. This is so that even on smaller viewports, the user sees a good visual representation of what the page template will look like to visitors of their site. On a technical level, this is done by applying a transform:scale() to the block-editor-block-preview__content element. The level of scaling is based on the user's current viewport size, and it changes dynamically when resizing the viewport.

The combination of transform:scale() and background-attachment:fixed leads to background-size:cover not calculating the cover value as needed. I did a bunch of research and testing today but unfortunately to my knowledge, there is no good fix for this issue that doesn't involve a considerable amount of JavaScript that either runs on every scroll or resize event for each instance of the block.

Proposed solution

The goal of the template previews is to provide the user with an idea of the result they will get when selecting a specific page template. To achieve this, the preview should match the visual appearance of the template but doesn't necessarily need to be fully interactive (in fact, we actually disable any type of user interaction with the preview).

With this in mind, I recommend we opt for the following pragmatic solution: in the template preview only, we set the value for background-attachment to scroll instead of fixed. This way, the visual representation of the block will be accurate as the background image will cover the full width of the block.

Visual result of proposed solution

[obenland]

Would this be fixed by #39628, when we don't need to scale the preview anymore?

[frontdevde]

Would this be fixed by #39628, when we don't need to scale the preview anymore?

I think the scaling of the preview has a different purpose and will stay in effect with #39628. IIRC the idea of the scaling is to always show a desktop style preview even on smaller viewports. The preview area is fairly small and without the scaling most of the time it'd show show tablet/mobile styles. This is just an assumption though, we might want to confirm with design.

[obenland]

@ianstewart Can we assume you prefer images filling their canvas over the parallax effect working in template preview? It looks like we can't have both.

[alaczek]

That sounds reasonable to me - at least this way images don't look broken.

[frontdevde]

Another thing to note:
The pragmatic solution I suggest is matching the way that Firefox deals with this problem. Firefox actually does something interesting, it seems to check whether a transform is applied on the positioning context. If so, it simply ignores the fixed value of background-attachment and treats it as scroll. This way it disables the Parallax but ensures that the element doesn't look visually broken. So my related PR simply implements the same behavior for other browsers as well.