[wp-trac] [WordPress Trac] #45985: Twenty Nineteen: Introduce better theme support for responsive images

WordPress Trac noreply at wordpress.org
Mon Jan 14 17:14:24 UTC 2019


#45985: Twenty Nineteen: Introduce better theme support for responsive images
---------------------------+-----------------------------
 Reporter:  kjellr         |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Future Release
Component:  Bundled Theme  |     Version:  5.0.3
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  performance
---------------------------+-----------------------------

Old description:

> As originally reported by @mor10, in the Twenty Nineteen GitHub
> repository:
>
> https://github.com/WordPress/twentynineteen/issues/50
>
> ----
>
> Currently, for images inserted within posts, the sizes attribute of the
> responsive images markup does not map to the actual displayed width of
> images.
>
> According to my tests (using a `1920x1080px` non-aligned image, inserted
> via Gutenberg (and set to `Image Size: Full`):
>
> The `sizes` markup is output as:
> `(max-width: 1920px) 100vw, 1920px`
>
> - At viewports `<300px`: A `300px` image is loaded
> - At viewports `>300px`: A `768px` image is loaded
> - At viewports `>768px`: A `1024px` image is loaded
> - At viewports `>1024px`: A `1568px` image is loaded
> - At viewports `>1568px`: The original `1980px` image is loaded
>
> Since this is not a full-width image, each of those image sizes is
> actually wider than necessary, resulting in a larger file size.
>
> For a more specific example: at a screen width of `1024px`, this non-
> aligned sample image is loaded in at `1568px` wide. As per theme rules,
> it actually appears only `700px` wide in the layout. On a non-retina
> screen, there's no need to load a `1568px` image for a `700px` space.
>
> Twenty Nineteen should include some theme-specific markup to properly
> assign `sizes` values that map to theme styles. This was done in Twenty
> Seventeen for instance:
>
> https://github.com/WordPress/WordPress/blob/master/wp-
> content/themes/twentyseventeen/functions.php#L491-L517
>
> At the time of writing, this issue is blocked by Gutenberg: We can
> currently issue a custom `sizes` attribute for non-aligned images like
> the example above, but it is not currently possible to have the theme
> customize the `sizes` attritbute for full/wide images. See the following
> GitHub issues for reference:
>
> https://github.com/WordPress/gutenberg/issues/6131
>
> https://github.com/WordPress/gutenberg/issues/6177
>
> https://github.com/WordPress/gutenberg/pull/11973
>
> ----
>
> I'm including patches ported over from two of @mor10's PRs on the
> original Twenty Nineteen repository:
>
> **Modifying the `sizes` attribute for non-aligned body images** (This
> currently causes negative results for `full` and `wide` images)
>
> https://github.com/WordPress/twentynineteen/pull/701
>
> **Adding custom `sizes` attributes, including `wide` and `full`
> variants** (This is dependent on Gutenberg #11973 being merged):
>
> https://github.com/WordPress/twentynineteen/pull/629

New description:

 As originally reported by @mor10, in the Twenty Nineteen GitHub
 repository:

 https://github.com/WordPress/twentynineteen/issues/50

 ----

 Currently, for images inserted within posts, the sizes attribute of the
 responsive images markup does not map to the actual displayed width of
 images.

 According to my tests (using a `1920x1080px` non-aligned image, inserted
 via Gutenberg (and set to `Image Size: Full`):

 The `sizes` markup is output as:
 `(max-width: 1920px) 100vw, 1920px`

 - At viewports `<300px`: A `300px` image is loaded
 - At viewports `>300px`: A `768px` image is loaded
 - At viewports `>768px`: A `1024px` image is loaded
 - At viewports `>1024px`: A `1568px` image is loaded
 - At viewports `>1568px`: The original `1980px` image is loaded

 Since this is not a full-width image, each of those image sizes is
 actually wider than necessary, resulting in a larger file size.

 For a more specific example: at a screen width of `1024px`, this non-
 aligned sample image is loaded in at `1568px` wide. As per theme rules, it
 actually appears only `700px` wide in the layout. On a non-retina screen,
 there's no need to load a `1568px` image for a `700px` space.

 Twenty Nineteen should include some theme-specific markup to properly
 assign `sizes` values that map to theme styles. This was done in Twenty
 Seventeen for instance:

 https://github.com/WordPress/WordPress/blob/master/wp-
 content/themes/twentyseventeen/functions.php#L491-L517

 At the time of writing, this issue is blocked by Gutenberg: We can
 currently issue a custom `sizes` attribute for non-aligned images like the
 example above, but it is not currently possible to have the theme
 customize the `sizes` attritbute for full/wide images. See the following
 GitHub issues for reference:

 https://github.com/WordPress/gutenberg/issues/6131

 https://github.com/WordPress/gutenberg/issues/6177

 https://github.com/WordPress/gutenberg/pull/11973

 ----

 I'm including patches ported over from two of @mor10's PRs on the original
 Twenty Nineteen repository:

 **Modifying the `sizes` attribute for non-aligned body images** (This
 currently causes negative results for `full` and `wide` images)

 https://github.com/WordPress/twentynineteen/pull/701

 https://core.trac.wordpress.org/attachment/ticket/45985/45985-regular-
 images.patch

 **Adding custom `sizes` attributes, including `wide` and `full` variants**
 (This is dependent on Gutenberg #11973 being merged):

 https://github.com/WordPress/twentynineteen/pull/629

 https://core.trac.wordpress.org/attachment/ticket/45985/45985-all-
 images.patch

--

Comment (by kjellr):

 There are many more details in the linked threads, but @mor10: feel free
 to add anything that I may have missed.

 Thank you!

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


More information about the wp-trac mailing list