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

max_alignment = default

Group (wide alignment) > Image

max_alignment = wide

Columns > Column > Image

max_alignment = default
column_width = 1

Columns > Column ( 50% ) > Image

max_alignment = default
column_width = 0.5

Group (Full alignment) > Columns (wide alignment) > Column ( 50% ) > Image

max_alignment = wide
column_width = 0.5

Columns > Column ( 50% ) > Columns > Column ( 33.33% ) > Image

max_alignment = default
column_width = 0.1667

[codecov]

Codecov Report

Attention: Patch coverage is 40.00000% with 21 lines in your changes missing coverage. Please review.

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

Files with missing lines	Patch %	Lines
...ns/auto-sizes/includes/improve-calculate-sizes.php	41.17%	20 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                                                              ?   69.41%           
=============================================================================================
  Files                                                                 ?       86           
  Lines                                                                 ?     7006           
  Branches                                                              ?        0           
=============================================================================================
  Hits                                                                  ?     4863           
  Misses                                                                ?     2143           
  Partials                                                              ?        0           

Flag	Coverage Δ
multisite	69.41% <40.00%> (?)
single	39.43% <40.00%> (?)

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.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[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.

[mukeshpanchal27]

+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.

What if we have columns block inside another columns block? I.e Columns > Column ( 50% ) > Columns > Column ( 33.33% ) > Image

[mukeshpanchal27]

@joemcgill @felixarntz Without WordPress 6.8, I can't traverse the context since we fixed that issue in Core for 6.8. So, I have to use version 6.8 here.

[swissspidy]

Suggested change

	"core": "https://wordpress.org/wordpress-6.8-beta1.zip",
	"core": "WordPress/WordPress#master",

Maybe this would make sense in general so that we always test against trunk?

[mukeshpanchal27]

Yes. Updated in b981edc

Just for information. Once 6.8 will release we update plugin minimum WP version to 6.8 and revert these changes so it will not affect other plugins.

[westonruter]

Maybe 6.8-RC1 would be better?

[mukeshpanchal27]

For now, let's leave it as trunk. Since WordPress 6.8 will be released in a few weeks, we'll need to revert these changes anyway.

[felixarntz]

@mukeshpanchal27

What if we have columns block inside another columns block? I.e Columns > Column ( 50% ) > Columns > Column ( 33.33% ) > Image

In that case the outer Columns > Column ( 50% ) would pass column_width: 0.5 to its child blocks, and then the inner Columns > Column ( 33.33% ) would pass column_width: 0.16665 to its child blocks (0.5 from the parent, multiplied with 0.3333 from itself). That's exactly why I think a single relative width value would work well, as it could be modified down the block children as needed.

[mukeshpanchal27]

#1913 fix the unit test issue

[mukeshpanchal27]

@joemcgill @felixarntz I have updated the PR as per the feedback. Could you please take a look so we can merge it and then proceed with #1818 for the code and unit tests for nested blocks?

Check updated PR description.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: mukeshpanchal27 <[email protected]>
Co-authored-by: joemcgill <[email protected]>
Co-authored-by: felixarntz <[email protected]>
Co-authored-by: swissspidy <[email protected]>
Co-authored-by: westonruter <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[felixarntz]

@mukeshpanchal27 This looks on the right track to me. A few comments below.

[mukeshpanchal27]

@felixarntz I’ve addressed the feedback, and the PR is ready for re-review.

[felixarntz]

@mukeshpanchal27 I think this looks pretty much good to go, but a few questions.

Maybe it's all good as is, it would just be great if you could double check and clarify.