Accurate sizes: Add ancestor block context

[mukeshpanchal27]

Summary

This PR add the ancestor block context for image and cover block that help to calculation of img sizes attributes.

See #1511

The context for ancestor block after the PR.

Group > Image

Array(
    [0] => Array( [core/columns] => default ),
)

Columns > Column > Image

Array(
    [0] => Array( [core/columns] => default ),
    [1] => Array( [core/column] => 100%)
)

Group > Columns > Column ( 50% ) > Image

Array(
    [0] => Array( [core/group] => default ),
    [1] => Array( [core/columns] => default ),
    [2] => Array( [core/column] => 50%)
)

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 10 lines in your changes missing coverage. Please review.

Please upload report for BASE (feature/1511-incorporate-layout-constraints-from-ancestors@3671902). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...ns/auto-sizes/includes/improve-calculate-sizes.php	68.96%	9 Missing ⚠️
plugins/auto-sizes/hooks.php	0.00%	1 Missing ⚠️

Additional details and impacted files

@@                                      Coverage Diff                                      @@
##             feature/1511-incorporate-layout-constraints-from-ancestors    #1795   +/-   ##
=============================================================================================
  Coverage                                                              ?   57.53%           
=============================================================================================
  Files                                                                 ?       84           
  Lines                                                                 ?     6544           
  Branches                                                              ?        0           
=============================================================================================
  Hits                                                                  ?     3765           
  Misses                                                                ?     2779           
  Partials                                                              ?        0           

Flag	Coverage Δ
multisite	57.53% <66.66%> (?)
single	34.65% <66.66%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joemcgill]

Thanks for getting this going @mukeshpanchal27. I can see where you're going but think that this introduces competing approaches to solving the same problem.

In #1701 we introduced the concept of max_alignment context, which is meant to be a way for ancestor blocks to share information about their alignment to inner blocks to use during rendering.

This approach is doing something similar by storing an array of the ancestor block hierarchy and their widths in a nested array that blocks can use during rendering.

Both have merits, but we should probably consolidate on one or the other approach and not both. In order to avoid passing a full array of block_width_data values to blocks that have to be looped through, we probably need to update the logic in auto_sizes_filter_render_block_context() that sets max_alignment context so that the alignment of a nested container block doesn't increase the max_alignment value.

For example, if you have a block structure like this:

group (align: 'default') > group (align: 'full') > image

The max_alignment context value should be 'default' since both the second group block and the image block will both be constrained by the max width of the first group block. However, we didn't consider nested blocks in the original implementation, so currently the max_alignment passed to the image will be 'full', resulting in an incorrect sizes value.

By handling nested alignment values with by keeping the max_alignment value updated we can avoid the need to pass the full array of nested block alignment values to the image block for it to loop through, like you're doing in #1818.

I do like the way you're calculating column widths by passing column_count context, but am think we might want to keep that context and container alignment width separate. What do you think?

[mukeshpanchal27]

@joemcgill Thanks for sharing your thoughts.

I tried reusing the max_alignment for nested blocks, but it became problematic in some use cases. Additionally, using a static variable to store the max_alignment caused issues, as detailed in the next block, leading to incorrect alignment details.

Could you please take a look and share your thoughts?

[felixarntz]

I mostly agree with @joemcgill's feedback. I believe the approach of a specific scalar value (like max_alignment) being passed down the block hierarchy is more straightforward to handle than an array of nested block data.

A few additional notes:

In #1701 we introduced the concept of max_alignment context, which is meant to be a way for ancestor blocks to share information about their alignment to inner blocks to use during rendering.

In addition to passing information about the alignment, we need to pass information about potential column widths (if columns are present). A potential approach would be a column_width context, which would be a number for the percentage of width. This could work as follows:

• Each core/column block determines this width % value based on its width within the parent core/columns block.
  • For example, a 3-column layout with equal sized columns would set this to 33% or 33.3333333% or 0.33333333 or something like that.
• The value is then passed through to child blocks.
• Any other core/columns + core/column blocks that may be encountered would receive the value and then calculate their width relative to the given value from the parents.
  • For example, if there was a 2-column layout within the above 3-column layout where column A is 2/3 of the width and column B is 1/3 of the width, the calculated value for column A would be 22.22222222% and for column B it would be 11.11111111%.

For example, if you have a block structure like this:

group (align: 'default') > group (align: 'full') > image

The max_alignment context value should be 'default' since both the second group block and the image block will both be constrained by the max width of the first group block. However, we didn't consider nested blocks in the original implementation, so currently the max_alignment passed to the image will be 'full', resulting in an incorrect sizes value.

I see where you are getting with this, but are you sure this is always the case? I'm pretty sure that I have seen full and wide alignment to be styled via some kind of vw unit, allow to span wider than a default container, even if that default container is a parent. I'm not certain either whether that's the case, but I think this may require some more research, e.g. looking at popular themes. How do most (or all?) block themes handle that?

By handling nested alignment values with by keeping the max_alignment value updated we can avoid the need to pass the full array of nested block alignment values to the image block for it to loop through, like you're doing in #1818.

+1

I do like the way you're calculating column widths by passing column_count context, but am think we might want to keep that context and container alignment width separate. What do you think?

+1 for keeping the two separate. I'm curious what you think about the above approach of passing down a single column width context value. The column_count is only relevant for each specific core/column block relative to its core/columns block, so that the core/column block knows how many siblings it has, in case it has no specific width provided.