Add fallback format support to responsive images

What is required to fix it?

Seems to me that webP only "works" on responsive images, not "native" images? Is this solvable in core at all as it means the result of the image style wouldn't be an <img> anymore but a <picture> once someone selects to convert it?

@mhercel: Could you find out which browsers in this liste are affected? https://www.drupal.org/docs/system-requirements/browser-requirements

Supported browsers

    The latest release of each of the latest two supported major versions of:
        Desktop browsers:
            Google Chrome
            Firefox
            Safari
            Microsoft Edge
            Opera
        Mobile browsers:
            Safari for iOS
    The latest supported release of the latest major version of:
        Desktop browsers:
            Firefox ESR
            Internet Explorer (Drupal 9 and below only)
        Mobile browsers:
            Chrome for Android
            Chrome for iOS
            UC Browser
            Opera Mini (except for 'extreme data savings' mode)
            Samsung Internet

Update:

Affected browsers:

• IE11
• (Safari)

See https://caniuse.com/webp

If this might be unsolvable for image formats (at least for older browsers) in the meantime core should perhaps adopt an option to responsive image styles instead?

The option for image formats could be kept, if everyone knows what he's doing... or add a warning note to the image effect?

@Mike you could check the existence of WebP images and serve them if supported. In Apache this could look similar to this:

.htaccess:

#WebP support
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_URI}  (?i)(.*)(\.jpe?g|\.png)$
  # For .jpg.webp/.png.webp file endings
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^ %{REQUEST_FILENAME}.webp [L]
  # For .webp file ending
  RewriteCond %{DOCUMENT_ROOT}%1.webp -f
  RewriteRule (?i)(.*)(\.jpe?g|\.png)$ %1\.webp [L,T=image/webp,R]

Just found this issue and had a think about it / did a bit of research.

https://www.drupal.org/project/webp supports fallbacks for webp images for browsers such as IE and Safari from contrib.

Drupal 10 has dropped support for all versions of IE, so we wouldn't add any new features to support IE specifically.

The latest couple of versions of Safari support webp, but only if you're on Big Sur or later. Catalina support is going to end in approx November 2022.

https://caniuse.com/webp

This means if we add some kind of polyfill via picture module for webp to core, it would fall under our browser support matrix for the next six months, but then be eligible for removal again - potentially still for 10.0.x if we end up releasing in December. Given there's not a viable patch here, I would tend to suggest that people use the contrib module for full webp support, and core's webp support will be sufficient for all modern browsers/supported OSs in approximately 6-9 months anyway. If there's another browser we support that can't handle webp yet though that might tip the balance towards adding this to 10.0.x

There's a further question whether we want to add a generic feature of allowing a format aspect to responsive image styles to address similar kinds of issues in the future - that might mean converting this to a task. This seems to be the only viable implementation here, we can't do it via pure image formats.

A further issue, due to an Apple bug, it's not possible to tell the relative usage of Catalina vs. Big Sur, because Big Sur reports itself as Catalina.

See the note and link on top of:
https://gs.statcounter.com/macos-version-market-share/desktop/worldwide

Going to go ahead and close this as won't fix.

Core currently makes it possible to configure a site such that it won't work on IE / and <= Catalina MacOS, but you have to intentionally configure it to transform images into webp.

Catalina support will end in approximately six months, that's the only configuration that Drupal 10 supports since support for all versions of IE was already dropped, and it probably won't be supported by the time Drupal 10 is released. If we had an RTBC patch here and it was a year ago, it might have been worth providing the workaround for webp support on Catalina, but at this point we'd be adding what is essentially a feature to responsive image module that will be obsolete in a few months. The contrib webp project is already there for sites that want to support IE/Catalina.

Thanks for caring, @catch! Totally agree with the decision due to the reasons given.

Re-opening this in light of #3202016: Let GDToolkit support AVIF image format which would add support for the AVIF format. AVIF also has (currently) spotty browser support, so it'd be viable to set up something like avif with a fallback to webp and then to the original image format.

as a feature it goes to 10.1

OTOH it means that 10.0 will be released with partial WEBP support

This is true but webp has been in for several releases now, so it's not a new situation.

Added rude mvp.

For every breakpoint we may create set of images.
Should be autocomplete form or draggable table here.

Tested with patch from https://www.drupal.org/project/drupal/issues/3202016 so AVIF was onboard aswell.

Created 2 images styles with convert to formats:
- AVIF
- WEBP

Output was:

<picture>
  <source 
    srcset="
    /sites/default/files/styles/avif/public/2022-08/cartman.jpg.avif?itok=GgUGobWL 1x, 
    /sites/default/files/styles/webp/public/2022-08/cartman.jpg.webp?itok=xTk6RNQX 1x, 
    /sites/default/files/styles/max_1300x1300/public/2022-08/cartman.jpg?itok=dmhT2n-4 1x" 
    media="all and (min-width: 1440px)"
  >
  <img src="/sites/default/files/styles/medium/public/2022-08/cartman.jpg?itok=dBR5G2t3" alt="cartman">
</picture>

In my chrome browser was loaded AVIF, in other WEBP will appear or even single breakpoint failback

https://caniuse.com/avif needs Safari 16.0 TP to be displayed

Overall great job! added some code-review

Main questions
- why 3 elements in srcset is enough to configure?
- how to extend/override it and how to configure defaults if webp, jpg I bet is used on mostly all sites and how to fit afiv when patch accepted

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Support having this awesome feature

Modules like Image Styles too with Responsive Image Style
and contrib modules like Dynamic Responsive Image (or drimage) will switch from using Webp to the Drupal core solution.

Can projects start using this fix? If it will be committed to Drupal Core 10.1.x or 10.0.x

It needs test and code comments - why 3 is enough!?

Anyone who is looking for some module in context of Drupal 10, can probably have a look here :
https://www.drupal.org/project/wpf

This module is good work around in context of fallback image support.

MR !2690 don't work as expected.

Tested in Drupal 11.

1. Leaving one single item with - none shows error.
2. Selecting two different image formats will merge both at the same srcset and the type attribute gets removed. This makes fallbacks useless. I already tested this behavior with an old browser version that does not support AVIF.

If the type attribute isn't specified, the browser retrieves the media's type from the server and determines if it can be displayed. If the media can't be rendered, the browser checks the next <source> in the list.

Quote from MDN.

Hacky workaround for image fallbacks using AVIF patch:
As Drupal 11 uses WebP by default, using 3202016 allow us to use AVIF images, then we create a copy of every image style but using AVIF (convert). In the current theme make an alternative breakpoint group with copies for every fallback, for example, X-Large (WebP) and X-Large (AVIF), Medium (WebP) and Medium (AVIF), it's important to set a weight to avoid headaches. This way, every fallback will get its own <source> with type. We need to select a single style for every breakpoint to get this working.

material_base.inline_images.lg:
  label: 'Large'
  mediaQuery: 'all and (min-width: 1024px)'
  weight: 6
  mutipliers:
    - 1x
  group: material_base.inline_images
material_base.inline_images.lg_alt:
  label: 'Large (alt)'
  mediaQuery: 'all and (min-width: 1024px)'
  weight: 5
  mutipliers:
    - 1x
  group: material_base.inline_images

material_base.inline_images.md:
  label: 'Medium'
  mediaQuery: 'all and (min-width: 768px)'
  weight: 4
  mutipliers:
    - 1x
  group: material_base.inline_images
material_base.inline_images.md_alt:
  label: 'Medium (alt)'
  mediaQuery: 'all and (min-width: 768px)'
  weight: 3
  mutipliers:
    - 1x
  group: material_base.inline_images
...

output sample:

<picture>
              <source srcset=".../styles/max_1300x1300_avif/public/inline-images/classic-sports.png.avif 1x" media="all and (min-width: 1280px)" type="image/avif" width="1240" height="826">
              <source srcset=".../styles/max_1300x1300/public/inline-images/classic-sports.png.webp 1x" media="all and (min-width: 1280px)" type="image/webp" width="1240" height="826">
              <source srcset=".../styles/max_650x650_avif/public/inline-images/classic-sports.png.avif 1x" media="all and (min-width: 1024px)" type="image/avif" width="650" height="433">
              <source srcset=".../styles/max_650x650/public/inline-images/classic-sports.png.webp 1x" media="all and (min-width: 1024px)" type="image/webp" width="650" height="433">
                  <img data-entity-uuid="f0f056a8-3db8-47c9-9dfa-dea98bf9c7d5" data-entity-type="file" data-responsive-image-style="inline_images" class="align-center inline-images image-style-inline-images" loading="lazy" width="1240" height="826" src=".../styles/max_2600x2600/public/inline-images/classic-sports.png.webp alt="abc">

  </picture>

Looking at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture for inspiration, I think what we want to generate is markup that looks like. Note in the first 2 <source/> tags, we add a type. In the 3rd, we can't because we have 2 types of images. The fallback is yet another image all together.

<picture>
  <source srcset="photo.avif" type="image/avif" />
  <source srcset="photo.webp" type="image/webp" />
  <source srcset="photo.png 1008w, photo.jpg 1312w" media="all and (min-width: 1000px)" sizes="100vw">
  <img src="photo.gif" alt="photo" loading="lazy" width="2000" height ="3000" />
</picture>

OOTB, right now, we can generate markup that looks like:

<picture>
                  <source srcset="/16_9_1008x567_focal_point_webp/public/2024-12/drupal-cms-hero.png.jpeg 1008w, /16_9_1312x738_focal_point_webp/public/2024-12/drupal-cms-hero.png.webp 1312w" media="all and (min-width: 1000px)" sizes="100vw" width="1312" height="738">
              <source srcset="/5_2_1000x400_focal_point_webp/public/2024-12/drupal-cms-hero.png.webp 1x" media="all and (min-width: 700px)" type="image/webp" width="1000" height="400">
              <source srcset="/16_9_704x396_focal_point_webp/public/2024-12/drupal-cms-hero.png.webp 1x" media="all and (min-width: 500px)" type="image/webp" width="704" height="396">
                  <img loading="eager" width="512" height="288" src="/16_9_512x288_focal_point_webp/public/2024-12/drupal-cms-hero.png.webp" alt="A bunch of laptops on a table from above">
  </picture>

What we don't have with core right now is the ability to have multiple image styles on a per image type. For the sizes option, I don't think that is critical. You can make it do what you want. (Please someone confirm this assumption).

What we need to address is Select a single image style.. We want to change that into multiple images. What I wonder is if we really want to do that or not. We really want that image "style" to have multiple image conversions. (Please confirm this assumption).

As AVIF been commited would be great to resurrect the issue, ref #3202016: Let GDToolkit support AVIF image format

It would be awesome to have a well defined way to define variants of image styles in core so contrib no longer needs to hack around this problem as is often the case. I think @heddn has the right idea, in that a single image style could generate multiple formats (or variants? Naming is hard) as opposed to the current limitation of a single image.

Adding #2986669: Split ImageStyle into the config entity and a separate event-based image processing service as related - that would probably help with image style variations idea.

However I'm not sure it should block this issue.

For AVIF and webp browser support is very high, so if we just fell back to the original image it would not be that bad IMO, would be a tiny fraction of requests.

Also because browser support is so high, this issue probably doesn't block using AVIF by default in core, the server-side requirements are more of an issue, but there is #3510582: AVIF conversion with WEBP fallback open for that.