[wp-trac] [WordPress Trac] #45407: Add block attributes to `wp_calculate_image_sizes` to allow for proper handling of `sizes` attribute

WordPress Trac noreply at wordpress.org
Sat Nov 24 07:52:48 UTC 2018


#45407: Add block attributes to `wp_calculate_image_sizes` to allow for proper
handling of `sizes` attribute
--------------------------+------------------------------
 Reporter:  mor10         |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Media         |     Version:
 Severity:  blocker       |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by azaozz:

Old description:

> Related Gutenberg issues:
> - 6177 https://github.com/WordPress/gutenberg/issues/6177
> - 6131 https://github.com/WordPress/gutenberg/issues/6131
> - 11973 (PR) https://github.com/WordPress/gutenberg/pull/11973
>
> Related Trac tickets:
> - #45406
> - #37840
>
> == Problem
> For images with no alignment or images where the image block is aligned
> `alignwide` and `alignfull`, the `sizes` attribute reads:
> ```php
> sizes="(max-width: 1024px) 100vw, 1024px"
> ```
> This means regardless of the displayed width of an image, the largest
> image file pulled by the browser is the generated 1024px image. If the
> displayed image width is wider than 1024px, the browser will stretch the
> image to compensate causing blur and artifacts.
>
> Historically this was solved by theme developers by augmenting the
> `sizes` attribute using the `wp_calculate_image_sizes` filter.
>
> The new `alignwide` and `alignfull` widths **cannot currently be
> accommodated** using this filter because the filter does not contain
> information about the alignment value of the containing block.
>
> == Proposed solution
> Modify the `wp_calculate_image_sizes` filter to include a new fifth
> parameter `$block_attr` containing an array which includes `[align]`
> which holds the alignment value for the containing block.
>
> This is a stop-gap measure as we wait for Gutenberg PR 11973
> https://github.com/WordPress/gutenberg/pull/11973 to merge.
>
> == Why this is a blocker
> From my perspective, this is a blocker to 5.0 for three main reasons:
>
> 1. As stated earlier, the current implementation of images means images
> with no alignment or images where the image block is aligned `alignwide`
> and `alignfull` are supplied with an incorrect `sizes` attribute by core.
> Theme developers cannot fix this because they have no way of filtering
> for different block widths. The end result is the visitor experiences
> blurry and/or artifact-heavy images which will be interpreted as an
> error. No theme (Twenty Nineteen included) handles responsive images
> correctly at the moment meaning all "Gutenberg-ready" themes with wide
> and full image options will display blurry/artifact-full images.
> 2. A solution to this problem must be one which stands the test of time.
> Once a solution is introduced, every theme (including core themes) must
> be updated. Shipping an interim solution which will later be changed puts
> an undue burden on theme developers and will impose legacy debt on
> WordPress Core to provide support for the interim solution in the long
> term. The proposal to add `$block_attr` with the `[width]` value to the
> `wp_calculate_image_sizes` filter is a mini version of what is proposed
> in Gutenberg PR 11973 and will be forward-compatible to more advanced
> images handling by themes.
> 3. 5.0 is shipping to millions of sites world wide. WordPress has a
> responsibility to follow web standards and use them correctly. The
> current implementation of the `sizes` attribute is insufficient and
> causes incorrect behavior for the end-user.
>
> == Further context
> -
> https://github.com/WordPress/twentynineteen/issues/50#issuecomment-436829300
> -
> https://github.com/WordPress/gutenberg/issues/6177#issuecomment-400095305
> - https://github.com/WordPress/twentynineteen/pull/629/files

New description:

 Related Gutenberg issues:
 - 6177 https://github.com/WordPress/gutenberg/issues/6177
 - 6131 https://github.com/WordPress/gutenberg/issues/6131
 - 11973 (PR) https://github.com/WordPress/gutenberg/pull/11973

 Related Trac tickets:
 - #45406
 - #37840

 == Problem
 For images with no alignment or images where the image block is aligned
 `alignwide` and `alignfull`, the `sizes` attribute reads:

 {{{
 sizes="(max-width: 1024px) 100vw, 1024px"
 }}}

 This means regardless of the displayed width of an image, the largest
 image file pulled by the browser is the generated 1024px image. If the
 displayed image width is wider than 1024px, the browser will stretch the
 image to compensate causing blur and artifacts.

 Historically this was solved by theme developers by augmenting the `sizes`
 attribute using the `wp_calculate_image_sizes` filter.

 The new `alignwide` and `alignfull` widths **cannot currently be
 accommodated** using this filter because the filter does not contain
 information about the alignment value of the containing block.

 == Proposed solution
 Modify the `wp_calculate_image_sizes` filter to include a new fifth
 parameter `$block_attr` containing an array which includes `[align]` which
 holds the alignment value for the containing block.

 This is a stop-gap measure as we wait for Gutenberg PR 11973
 https://github.com/WordPress/gutenberg/pull/11973 to merge.

 == Why this is a blocker
 From my perspective, this is a blocker to 5.0 for three main reasons:

 1. As stated earlier, the current implementation of images means images
 with no alignment or images where the image block is aligned `alignwide`
 and `alignfull` are supplied with an incorrect `sizes` attribute by core.
 Theme developers cannot fix this because they have no way of filtering for
 different block widths. The end result is the visitor experiences blurry
 and/or artifact-heavy images which will be interpreted as an error. No
 theme (Twenty Nineteen included) handles responsive images correctly at
 the moment meaning all "Gutenberg-ready" themes with wide and full image
 options will display blurry/artifact-full images.
 2. A solution to this problem must be one which stands the test of time.
 Once a solution is introduced, every theme (including core themes) must be
 updated. Shipping an interim solution which will later be changed puts an
 undue burden on theme developers and will impose legacy debt on WordPress
 Core to provide support for the interim solution in the long term. The
 proposal to add `$block_attr` with the `[width]` value to the
 `wp_calculate_image_sizes` filter is a mini version of what is proposed in
 Gutenberg PR 11973 and will be forward-compatible to more advanced images
 handling by themes.
 3. 5.0 is shipping to millions of sites world wide. WordPress has a
 responsibility to follow web standards and use them correctly. The current
 implementation of the `sizes` attribute is insufficient and causes
 incorrect behavior for the end-user.

 == Further context
 -
 https://github.com/WordPress/twentynineteen/issues/50#issuecomment-436829300
 -
 https://github.com/WordPress/gutenberg/issues/6177#issuecomment-400095305
 - https://github.com/WordPress/twentynineteen/pull/629/files

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45407#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list