Request for feedback: Image Component ‘Raw’ layout

[atcastle]

Starting with version 12.1.1-canary.11, I’ve added experimental support for a new image component mode layout mode called “raw”. This mode removes the spacers and styling associated with next/image’s responsive behavior, rendering a “raw” image element with no styling. The component still requires height and width information in order to prevent layout shift, and will pass those attributes to the underlying image unless you also provide a sizes attribute, which indicates that the image is expected to behave responsively.

I have also enabled the use of the style attribute in all image modes to pass style properties directly to the underlying image element. Be aware that in layout modes other than ”raw”, any styling required for that layout mode will take precedence over provided styling, if there’s a conflict.

I would like to gather feedback on the new ”raw” layout mode before we move it out of experimental. I encourage anyone who’s had trouble getting the next/image component styled the way they want to try the experimental ”raw” layout and tell me how it worked.

See this section in the documentation for how to enable the experimental layout mode.

---

Here’s an example template for responses, though any feedback is appreciated:

1. What layout / styling behavior were you previously unable to accomplish with next/image?
2. What layout modes did you try?
3. Did the experimental ”raw” layout mode solve your problem?
 - If not, what changes would allow it to solve the problem?
4. Do you have any additional feedback about the new mode or its documentation?

[Redskinsjo]

Hi, I am using Next with Typescript and it seems that layout="raw" causes an error because Typescript doesn't recognize "raw", as I am trying to position the Image as relative.

in VSCode : Type '"raw"' is not assignable to type '"fixed" | "fill" | "intrinsic" | "responsive" | undefined'.ts(2322)
in Browser : Error: Image with src has invalid "layout" property. Provided "raw" should be one off ill,fixed,intrinsic,responsive,undefined.

[stefanprobst]

yup, seeing the same error:

[styfle]

You'll need to update to Next.js 12.1.1 or newer: npm i next@latest or yarn add next@latest

[OskarGroth]

Seems to be working well with TypeScript here.
This is a great addition, it solves many issues with layout that I've experienced while using Image. But still doesn't cover the one use case I think the Image component lacks the most.

What layout / styling behavior were you previously unable to accomplish with next/image?

The image component desperately needs a way to define art direction. That is, to be able to provide different images at different breakpoints.

i.e, something that matches the following:

<picture>
    <source srcset="mobile.jpg 1x, mobile_2x.jpg 2x" media="(max-width:734px)">
    <source srcset="desktop.jpg 1x, desktop_2x.jpg 2x" media="(min-width:0px)">
    <img src="desktop.jpg">
</picture>

What layout modes did you try?
Did the experimental ”raw” layout mode solve your problem?
 - If not, what changes would allow it to solve the problem?

I've tried all layout modes. The problem stems from the fact that the developer has very limited control over the generated srcsets.

Either you use responsive or fill and have your image generated in like 10 different sizes (none of which are relevant because I only want my image generated in 1x or 2x size). Or you define width & height while using fixed or raw and get precise 1x and 2x sizes. But there is no way to do that while also defining a different image for a different viewport.

I think that it should be possible to allow for the user to supply alternative src (with separate width and height for each) for alternative media breakpoints.

Do you have any additional feedback about the new mode or its documentation?

The documentation lacks a demo, instead there is a link to "Demo Background Image" which is a bit confusing since it doesn't seem to be using raw.

[pdkn]

Take a look how Imgix handles picture tag for art direction https://reactjsexample.com/react-component-to-display-imgix-images/. Something like this is desperately needed in nextjs.

<Picture>
  <Source
    src={src}
    width={400}
    htmlAttributes={{ media: "(min-width: 768px)" }}
  />
  <Source
    src={src}
    width={200}
    htmlAttributes={{ media: "(min-width: 320px)" }}
  />
  <Imgix src={src} width={100} />
</Picture>

[jakevoytko]

I just tried out the raw layout.

What layout / styling behavior were you previously unable to accomplish with next/image?

I had a menu dropdown that overlayed some next/image instances. The next.js Image component created its own stacking context independent of the absolute-positioned dropdown, and no amount of cajoling or convincing made the stacking context of the images appear lower in the 3d layout of the page than the menu. I skimmed the source of next/image and it seemed like it wasn't configurable enough to remove the style data responsible for creating the independent stacking context. I found other bugs where the recommendation was to make the other element have a different position type, which I could not do because my dropdown requires absolute.

What layout modes did you try?

I cycled through all of them, but I did not read the documentation on any of them ; I was sick of wrestling with z-indices and stacking contexts at this point and was just hoping one would insta-work.

Did the experimental ”raw” layout mode solve your problem?
 - If not, what changes would allow it to solve the problem?

raw layout worked as a drop-in replacement (visually).

Do you have any additional feedback about the new mode or its documentation?

This worked as a drop-in replacement for my specific use case, so it's hard to say.

[OskarGroth]

I also think that it doesn't make any sense to base image sizes generation (1x, 2x) on some array of constants defined in next.config.js. It already barely made sense for the other layouts, but even less so for the raw layout where you probably always want to define generated image sizes to be derivatives of the already provided width.

If I have a 1200x800 image in 2x DPI and want to support generation of 1x, 2x sizes with the fixed/raw layout, I have to do this:

<Image width={1200} height={800} layout={'raw'} src='.../image.jpg'/>

And then in next.config.js:

module.exports = {
    ...
    images: {
	// Super stupid, but must remember to add images sizes (1x AND 2x) here in order to generate correct 1x 2x srcsets.
	// NOTE: Cannot safely remove entries from here without checking all existing images.
	imageSizes: [..., ..., 1200, ..., ..., 2400, ..., ...]
    }
}

This is incredibly frustrating and error-prone. Right now this array is bloating up to 100+ entries to support all images on my site. NextJS Image should support generating this automatically.

[predaytor]

I use sizes this way:

deviceSizes: [576, 768, 1024, 1440, 1920].flatMap(size => [size, size * 2]),

[pdkn]

because 'raw' has image format connotations. Maybe consider using layout="none" or layout="vanilla" ?

[mlstubblefield]

This is less feedback for raw and more just next image in general, but because safari (which obviously has a huge amount of market share) doesn't support imagesrcset on preloads, our LCP gets hurt pretty bad. I have a bit of a hack where I preload my own (reasonably large with low quality) image right "behind" (using z-index) a next image and it seems to kind of work, but it'd be nice if next image had something nice for Safari. I think the downside here is that webvitals doesn't count on Safari.

[Aex12]

I've been using the raw layout lately on a project. Here are my thoughts:

What layout / styling behavior were you previously unable to accomplish with next/image?

I needed to make a simple layout like this:

<div className="w-full flex space-x-16">
  {clients.map((client, index) => (<img src={client.logo} classname="h-16 w-auto" />))}
</div>

this makes a row containing images of different sizes, all adjusted to the same height, but with different widths depending on the original image aspect ratio. All of them have the same horizontal spacing between them no matter its width. This works flawless with the vanilla <img /> component with any image, even if I don't know its height and width properties beforehand

What layout modes did you try?

I tried every single layout and read the reference docs thoroughly but couldn't make it work with the <Image /> component (I could only make it work using layout=raw and providing correct height and sizes values)

Did the experimental ”raw” layout mode solve your problem?


Somehow. If I provide the src property as an string referencing an external image from which I don't have the correct width and height values, it wont work because it'll refuse to compile if I don't provide that two parameters. Providing arbitrary values will make the image to resize to aspect-ratios other than its original.

If I render the Image as an Static Import, but I don't provide any value to the sizes parameter, it'll cause the image to not fit correctly into my layout. If I use it as a Static Import, and provide a sizes parameter, it works as expected.

If not, what changes would allow it to solve the problem?

I think the Image component should be able to be rendered without providing any width or height values, just like with the "fill" layout. I've also seen that even it being a "raw" layout, it adds some width and height properties when "sizes" is not defined. It also adds on every case { aspectRatio=width/height} styling to the img component and it can't be overridden. I would expect a raw layout to not interfere with the underlying component and just provide the correct srcset and scaling

[iojcde]

This is much better than without the raw layout, but I’ve yet to find a way to make an Image component scale automatically to fit the parent’s height.

I know that providing values for height and width will prevent layout shift, but there are certain use cases where I personally would prefer to compromise a tiny bit of layout shift, in order to reduce the complexity needed to calculate all the images's optimal widths.

In the above image, all of the images scale down to fit the parent's height, as I didn't provide the width, just the height. However, next/image with the raw layout mode requires you to provide values for the width & height.

It would be useful to have a way to override this behavior, but while having the current state as the default.

[knetcode]

What layout / styling behavior were you previously unable to accomplish with next/image?

Strict CSP rules, not allowing any inline styles / scripts etc.

What layout modes did you try?

All of them

Did the experimental ”raw” layout mode solve your problem?
 - If not, what changes would allow it to solve the problem?

Mostly, the raw layout still adds a style attribute with aspect ratio though. It doesn't break the image or anything, the image still works as intended, but my CSP policy still chucks out errors in the console.

Do you have any additional feedback about the new mode or its documentation?

Not sure if there's a reason that this is being added, but perhaps if we could turn it off? Pass a prop the disables all inline-styles from being applied?

[leerob]

This isn't 100% related to the raw layout, but wanted to mention it here as I close out the discussion. We have extracted the core logic from next/image into a new unstable_getImgProps() function.

This allows usage outside of <Image>, such as:

1. Working with background-image or image-set
2. Working with canvas context.drawImage() or simply new Image()
3. Working with <picture> media queries to implement Art Direction or Light/Dark Mode images

Example

import { unstable_getImgProps as getImgProps } from 'next/image'

export default function Page() {
  const common = { alt: 'Hero', width: 800, height: 400 }
  const { props: { srcSet: dark } } = getImgProps({ ...common, src: '/dark.png' })
  const { props: { srcSet: light, ...rest } } = getImgProps({ ...common, src: '/light.png' })

  return (<picture>
  <source media="(prefers-color-scheme: dark)" srcSet={dark} />
  <source media="(prefers-color-scheme: light)" srcSet={light} />
  <img {...rest} />
</picture>)
}

PR: #51205