Incorporate layout constraints from ancestor blocks into the sizes calculations

[joemcgill]

As outlined in #760, the initial work for accurately setting the sizes attribute for image and cover blocks has been released through the Enhanced Responsive Images plugin. While the current implementation effectively handles individual image blocks, it does not account for images constrained by other ancestor blocks. This issue aims to address this issue by focusing on multiple block types, including column, group, row, and stack blocks (alignments only). Enhancements for grid blocks are also being considered (though they are of lower priority due to their complexity and recent introduction).

The primary goal is to improve the sizes attribute across these block types to ensure images are displayed with the correct sizes for optimal rendering across different screen sizes.

[joemcgill]

@mukeshpanchal27 and I have been exploring this issue over the last several weeks and I wanted to give a quick progress update.

Technical discovery

In order to incorporate layout information from column, group, row, and stack blocks that are ancestors of images, we considered several different approaches.

Use “wp_calculate_image_sizes directly

Modifying the wp_calculate_image_sizes filter seems like the most straightforward was to improve the calculation of the sizes attribute. However, one of the key challenges is that this filter does not receive any layout information from the block context, which is crucial for accurately determining the appropriate sizes value for images. Instead, that function is only aware of the img markup itself, not even the figure that wraps the img and provides its own layout alignment.

We created an experimental plugin to demonstrate a proof of concept for calculating the sizes value during block rendering, when more information is available. However, this approach is a bit fragile and will result in a DB query for each image.

Hooking into the block rendering process

In this approach, layout constraints would be passed from ancestor blocks to images using block rendering filter render_block_data. Inspired by how the core gallery block handles this process.

While this approach could work, we quickly found that passing block layout information down to innerBlocks was not performant.

Passing layout information as block context

In this approach, layout constraints would be passed from ancestor blocks to images using block context.

Before each block in a layout is rendered, context can be used to pass information about the current state of WordPress or information from parent blocks to their inner blocks. We can make use of this functionality by hooking into the render_block_context filter to capture information from a parent block—like the parent’s alignment or existence of sibling blocks—and set this as context that can be accessed by the image when the sizes attribute is being calculated.

Some initial experiments with this approach have been promising and looks to be the best approach to pursue at this time.

In the process of working on this approach we ran into the same bug reported in Trac#62046 and have been helping find a fix via WordPress/wordpress-develop#7344 and WordPress/wordpress-develop#7522.

Next steps

At this point, we're planning on moving forward on an implementation based on using the block context approach described above. This will likely be done in multiple PRs that focus on specific aspects of this problem (e.g., passing layout from columns to a nested image, passing layout from a group block, etc).

Any new issues related to this effort should be added as sub-issues of this one to track progress. All PRs should target the newly created feature/1511-incorporate-layout-constraints-from-ancestors branch that has been created for this effort.

[joemcgill]

To help with implementation of this issue, I'm listing some use cases we need to solve for

• Accurate sizes: Calculate image sizes during block rendering #1625
• Pass alignment information to image blocks via block context for column, group, row, stack and grid blocks
• Account for inner blocks using content width for columns and group blocks (Note: custom width option is lower priority)
• Use block context to pass layout info from columns:
  • Account for relative column widths based on column counts (2 columns, 3 columns, etc)
  • Account for columns with relative widths (e.g., 33.33%, 66.66%)
  • Account for specific column widths (e.g. 50%, auto, auto)
• Support nested container blocks (e.g. group > columns, group > group > columns)
• Account for row blocks with “Allow to wrap multiple lines” option