#responsive images

The two ways in which CSS is involved include:

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

IMHO a major part of this is the CSS that goes with the image, so in the examples in #23 there might be CSS that also affect how the image is being displayed.

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.

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?

As far as the browser selecting the best image, we provide a list of images to the browser and let the browser know how big each image is using the `w` descriptor. Then in the sizes attribute we tell the browser how big/small we want the image to be rendered allowing the browser to select the best image based on viewport width, screen resolution, network speed, etc.

In my opening comment at the beginning of this issue you will see a screenshot for the configuration I just described. However, in my code example in the previous comment, the width and height values are present in the img tag. How did they get there? Was that Drupal after the page was rendered?

BTW it's not technically possible to set the image's width and height attributes to the specific image variation the browser will use as the HTML tag is generated at the server, and the server doesn't know what the browser is going to do with it.

I wanted to know what the recommended solution was for the "width" and "height" attributes when using responsive images.

I couldn't find any recommendations on Mozilla's dev article on the topic or their <img> docs page.

I did find this article:

• https://chipcullen.com/what-width-and-height-attributes-to-use-with-resp...

The article says "Set width and height to the resolution that corresponds to your default src." That suggests that Drupal core's handling of these attributes is correct and that we should close this as "won't fix".

@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="small.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

Thank you for the patch. #11

Could you please clarify what the HTML looks like before and after this change? I think that would help everyone understand what is happening. Thank you.