gatsby-image fluid / fixed are to narrow in their use-cases

[martin-braun]

When using Gatsby Images we are given two choices:

1. fixed - show image with fixed image size, will include CSS to fix the size on the client, too
2. fluid - show image with vary image size that scales with screen size, will include CSS to vary the size on the client, too

What I miss is the possibility to have a fixed image size in a dynamic container. For instance, when I display the image within a column that will wrap on mobile (i.e. Bootstrap column), the image will also be small on larger screens, because the client will show columns next to each other.

If I select fixed, the CSS will prevent my image to be 100% width. I don't like hacks.

If I select fluid, it will download a large version of the image for a larger screen, although the image will never be displayed large on the client.

[LekoArts]

You should give #27950 a try then, it has a constrained layout option :)

[sandren]

There have been some absolutely incredible improvements in the new <GatsbyImage> component (I'm happily using it on several websites in production! 😁), but I feel like this specific issue is still very much a valid concern.

The problem is if you use a FULL_WIDTH image at anything less than 100vw wide, then Google Lighthouse will penalize your site for not "properly sizing images".

This happens even if you properly follow the documentation and, for example, set the appropriate sizes: 25vw and make very small assets available via breakpoints: [240, 320, 480, 640, 768, 1080, 1366, 1920]. In this case it will still serve the largest image even when it's only rendered at around ~500px, which it should know via sizes="25vw" in a ~2000px wide browser window.

@ascorbic and I have been trying to troubleshoot this issue in the main <GatsbyImage> thread, but I think this a critically important enough issue for it's own discussion here. Only once Gatsby sites aren't penalized In Lighthouse for using non-100vw FULL_WIDTH images can we safely say this issue is resolved. 😀

[ascorbic]

@sandren This is a different issue though. We have an API to do exactly what you need. It just wasn't passing sizes through properly. The fix is #29192, but that just needs a release

[sandren]

@ascorbic Oh, ok! So this particular issue I'm mentioning is basically resolved as of the next release? This is great news! 😅

So after this fix is released, is there still a reason to use the new CONSTRAINED layout over the FULL_WIDTH option if sizes + breakpoints does the same thing for FULL_WIDTH images? Because at that point we're basically still working with "full-width" images, but just the full-width of it's container, not the screen.

I'm just trying to fully understand all of the best practices and workflows with respect to the new <GatsbyImage> component. Thanks again! 😊

[ascorbic]

Breakpoints don't constrain the container, they just control the generated output sizes. Constrained does not expand beyond the specified width, or the intrinsic width of the source image. It is the one you should use if the image will have a fixed maximum size, rather than resizing infinitely with the container. Look at the video on this page to see the difference.

[sandren]

@ascorbic If an image never spans the full-width of the screen—but always the full-width of its container—and the container itself eventually has an upper limit on its width at a sufficiently high resolution, would you want to use CONSTRAINED with sizes and a very carefully selected width or would you want to use FULL_WIDTH with both sizes and breakpoints specified? 🤔

I'm thinking the problem with CONSTRAINED in this situation is that if for some reason the container is even slightly bigger than the specified width (because in CSS you're working with responsive ems/rems/ch/vw/% units while with <GatsbyImage> you're working with hard-coded pixel values), then it will break the intended layout while FULL_WIDTH would still continue to span the full-width of the container as you would want.

Maybe there is some sort of compromise where CONSTRAINED can be made to behave like a FULL_WIDTH image as far as working with it in the browser (always spanning to the full-width of its container), but the specified width is expected to generally match the maximum width of it's container? Basically if your ems/rems/ch/vw/% width of the container renders slightly bigger than the pixels you give the <GatsbyImage>, the image will stretch a little bit and give you the benefit of the doubt as to not break your intended design.

If this can't be made to be the default behavior, perhaps there can be an extra flag made available to CONSTRAINED images to make it behave like this? Like specify maxWidth: fluid (default: fixed) to make it behave like a FULL_WIDTH image in the browser, but otherwise use the CONSTRAINED API?

Basically I think it's common for a container to have a maximum width in general (through ems/rems/ch/vw/%), but less common for that container to have its maximum width specified in hard-coded pixel values, which is what makes CONSTRAINED a bit unwieldy in modern, responsive web design. 😃

[ascorbic]

In that case I'd just set the width a little bit larger than the expected max width.