Image width/height from fallback image breaks responsive images

I did additional research and testing using vanilla installations of Drupal 10.x.

First test - Using fallback image width and height

Expected behavior, image should render large on desktop (max 1290px), and full width on mobile.

1. First I configured responsive images (resp-img.png)
2. While inspecting the image, visually it looks tiny and that's because it is using the fallback image dimensions (dimensions.png)
3. However, looking at the Network tab in the dev tools, we see the right image is loaded, but because Drupal is changing the width and height of the img tag based on the fallback image dimensions (network.png)

Second test - Not using fallback image

1. Same responsive image configuration as above
2. Inspecting the image this time, reveals the right width/height on the image tag which is provided by the Sizes configuration in item #1 above.
3. The Network tab in inspector's console displays the right image dimensions and visually the image also looks correct (dimensions2.png)

Conclusion

Drupal is able to provide the right width and height to the img tag without resourcing to the fallback image. Hoping this can be resolved to be able to effectively use responsive images.

@agarzola, that a great question and that's the beauty of using srcset and sizes image attributes. The srcset lets you define a set of images each of which includes its width, allowing the browser to select the best image based on its width and the desired rendering size which is provided as part of the sizes attribute.

@agarzola, I see what you mean. I think the width/height should be the one from the image selected by the browser. The browser analyzes the srcset and sizes attributes values then picks the best image that meets the rendering criteria, among other things. Up to this point, this has been the default behavior until I started seeing issues with fallback image width/height being applied to the img tag (thus this issue). By the way, this only seems to be an issue with srcset/sizes and not <picture>.

This patch removes the fallback image dimensions so they are not forced into the width/height attributes of the img tag.

Yes @agarzola, my answers remains the same. The width/height values for the HTML attributes should be those of the image selected by the browser. My argument is that what is the point of configuring responsive images with specific loading criteria, if they will be overriden by using fixed values from a fallback image?

As for issue 3359421, If thats where the breaking changes were introduce, then I would think they need to be implemented differently.

I appreciate your feedback and I hope with the help of the community we can come up with a solution that will work for everyone while adhering to the standards of responsive images.

Hey there! I wanted to share some clarifications about this patch that might be helpful:

1. Just a friendly reminder that the fallback image isn't meant to be your primary image solution. It's simply a safety net for browsers that don't support the srcset and sizes attributes (which is quite rare these days!). Since all major browsers have supported these features since 2017 (you can check out https://caniuse.com/?search=srcset for details), you probably won't need to rely on the fallback much at all.
2. When you're using srcset and sizes, the browser automatically handles the image's width/height values. Each image in the srcset includes its width information, which helps the browser make smart decisions and apply the right dimensions to the image tag.
3. When we force responsive images to use fallback image dimensions, we're actually undoing all the benefits of responsive design. The whole point is to let the browser choose the best image based on the user's device, screen resolution, and network conditions. By forcing a specific size, we're essentially going back to the pre-responsive era when we had to use one-size-fits-all images.
4. If you're noticing layout issues, it might be worth revisiting your overall layout strategy. Ideally, your markup and CSS should work together to create flexible layouts for different breakpoints, with images naturally fitting their containers. A simple CSS rule like img { height: auto; max-width: 100%; } can ensure images never exceed their containers. Remember that your layouts should determine how images appear, while responsive images deliver the most appropriate file for each situation.

I hope this helps understand what's in play here.

@damienmckenna, certainly. The HTML does not look much different before/after the patch is applied. I've cleaned it up for better readability.

Before

<img loading="eager" 
  srcset="small.webp 360w, medium 480w, large.webp 768w" 
  sizes="(max-width:768px) 100vw, 720px" 
  width="480" 
  height="360" 
  src="medium.webp" alt="Image alt text">

After

<img loading="eager" 
  srcset="small.webp 360w, medium 480w, large.webp 768w" 
  sizes="(max-width:768px) 100vw, 720px" 
  width="768" 
  height="512" 
  src="medium.webp" alt="Image alt text">

The difference after the patch is applied is that the width and height of the img tag is set/forced to be that of the fallback image rather than using the dimensions of the image the browser has selected. As you can see, each image in the srcset has a width defined (i.e. 768w, this value is to instruct the browser how big this image is and in combination with the query in the sizes attribute, the browser is able to select the best image to meet the developer's intended rendering goal.
By using the fallback image dimensions as the img width/height, we are bypassing the concept of responsive images.

Here are before/after screenshots which show the issue when the fallback image is smaller than the size of the intended image. Some may say: "Why not use a larger fallback image?", true, but again, the whole goal of responsive images is for the browser to analyze the environment and select the best image for the job. In addition, what if I am dealing with an image that is, say, 2600px? this means my fallback image would need to be that large which I don't think is the best approach.

Before

After

Yes, this is not an easy issue due to your last point of the server not knowing what the browser will do.
This may be a silly question, but based on the code examples in my previous comment, how were the width/height set? Was it Drupal doing that after the page was rendered?

I feel like responsive images works well when we let the browser do its job, but I do understand that in some cases there might be content shift when images don't contain a width/height. My concern with forcing a static width/height on the img is that this defeats the purpose of responsive images. So the question is, is there another way to capture width and height that is based on the image actually being selected by the browser rather than a random fallback image which purpose is simply to be used when browsers don't support responsive images?

On smaller images, using a fixed image may work just fine and we wouldn't even need responsive images. This is the approach I take when images are intended to be rendered at a relatively small size across all breakpoints. However, when it comes to large images such as Hero images or full width images, this is when responsive images shine and using the fallback image approach would result in either upscaling images with CSS which is not recommended, or, using extremely large images as fallback which in turn will affect performance and maybe even UX.

I think there may be some level of CSS involved in process. Here are the most common ones:

1. Using the following global rule: img { max-width: 100%; height: auto; }. This rule is pretty much best practice on most projects. It ensures the image never exceeds the width of the container it is in, and the image width will never be upscaled beyond its original image size.
2. Other part where CSS plays a bigger part is in layouts. With the CSS rule above, the image will work in most cases as long as your layouts have been properly established using any of the available methods such as CSS Grid, Flexbox, plain'ol dimension settings on containers.
3. Using CSS' aspect-ratio property can help the browser predict what the image approx size or aspect ratio will be.

It's not common practice to resize the actual <img> tag only using CSS. The recommended approach is to manage layouts around the image and images should naturally adapt to the layout containers.

The last point about using CSS for image dimensions, yes, it is true that you can actually resize images to the desired dimension with CSS, but just like images, CSS also need to be fully available during the page load process for those rules to kick in.

I feel like the issue is not so much the size of the image, the browser is already taking care of that for us, but just as important, is assigning the right width/height values to the img tag at load time (ideally the same dimensions the browser selected), to avoid affecting Largest Contentful Paint

Updated requirements for patch.

Added issue reference about 11.3 change.

Added new patch for Drupal core 11.3 or higher.

For Drupal <= 11.2.10 use the patch in comment #17

For Drupal >= 11.3 use the patch in comment #37.

See 3548329 for details.

Added patch tests.

Created a MR from patch in comment #37. I'd appreciate your feedback: MR/14162

Thanks for the feedback, @smustgrave. I'll add test to the MR.

Update the Functional tests with backwards compatibility.