(srcset) sizes attribute

[strarsis]

It would be great if the sizes attribute can be supported directly
so responsive images with srcset can work correctly.
sizes attribute maps viewport to image size in advance -
the blocks in gutenberg are influenced by parent blocks and influence image dimension themselves.

[jasmussen]

This seems like a great candidate for inclusion in the inspector. See #16 and #672

[strarsis]

An example: Some theme that defines a content area which can be edited by this new editor.
The editing user wants in a row an image block, then a text block and then again an image block.
The image blocks should extend to full available width (e.g. 33%).
Now the theme content area is already constrained by the theme,
the image blocks and text block, with their own widths share this available content area width.

For the browser to pick the right image file already during parsing (which is the point of using srcset sizes attribute) it must know the width of the image on the finally rendered page in advance.
image width = calc(theme content area width (e.g. 80em) * block width in % (e.g. 33%))
And the theme content area may be also influenced by media queries (breakpoints),
so multiple media queries have to be added to sizes attribute, too.

It may be a good idea to let the theme report the available content area dimensions with
media queries so this new gutenberg editor can use it for the calculation -
or at least inject it into the sizes attribute using calc.

[azaozz]

Been thinking what's the best way to do this. There are two sides:

1. Showing high-res images in Gutenberg (with srcset and sizes).
2. Keeping these attributes in post_content. This will bypass the display filter that currently adds them dynamically for each image on the front-end and reduce server load (sometimes significantly).

There is one problem with full-width images: Gutenberg's width is different from the theme's width. That means we will have to add sizes for full-width images inside the editor (so the images display high-res), but then strip this attribute on saving the post. Then will have to still process these images with the front-end display filter and add appropriate sizes.

If we keep srcset and sizes (when the image is not full-width), we would still need to have a display filter so plugins can reset them. We've talked about this approach few times in #core-media on Slack, thinking it's about time to implement it :)

Can also look at changing the way we "discover" local images that are processed by that filter, perhaps a data-wp-* attribute with the attachment ID and available sizes, etc.

[afercia]

Just noticed that, when converting an existing post, when it's initially rendered in the "Classic" block the srcset/sizes thing works in the frontend. But, as soon as you convert the single Classic block in Gutenberg blocks (via ellipsis menu > Convert to blocks), it stops working.

As a site owner/maintainer, I wouldn't be so happy to see my frontend markup suddenly changing to something that is a pejorative experience for my users. Not sure why this issue is marked as "Priority low", as any change to the actual frontend content should be avoided at all costs.

[mor10]

What's the status here? And how does this impact theme/plugin developers? In 'old' WP, we would hook into the wp_calculate_image_sizes filter to set the sizes attributes for content images based on the content width. Since content width is now only one of several factors, we need more granular control to set the sizes attribute for regular images, wide images, and full images. Has this been resolved, and if so is there any documentation floating around I'm not smart enough to find?

[strarsis]

@mor10: Hopefully one day browser support for the FLIF image format becomes widespread enough so the bulk of srcset/sizes related optimizations becomes unnecessary. 😸