Replies: 8 comments 15 replies
-
Hey! Thanks for opening this. The team is currently busy preparing for Next.js Conf in a week but will provide a response here after |
Beta Was this translation helpful? Give feedback.
{{editor}}'s edit
{{editor}}'s edit
-
Hello, I'm fully supportive of this initiative. I would like to add some additional information regarding this task on the top of managing optimized picture size based on device and density:
<picture>
<source srcSet="/vercel_dark.svg" media="prefers-color-scheme: dark" />
<img src="/vercel.svg" alt="Vercel Logo" />
</picture>
So it can be great if we can add a kind of specific custom rules and let Like:
<source srcSet="/vercel_dark.svg" media="prefers-color-scheme: dark" />
</Image>">
<Image src="/vercel.svg"> <source srcSet="/vercel_dark.svg" media="prefers-color-scheme: dark" /> </Image> |
Beta Was this translation helpful? Give feedback.
{{editor}}'s edit
{{editor}}'s edit
-
@atcastle are there any news on supporting picture within next/image or can we help there somehow? |
Beta Was this translation helpful? Give feedback.
-
Any updates on this issue? |
Beta Was this translation helpful? Give feedback.
-
any update ? |
Beta Was this translation helpful? Give feedback.
-
Will be sharing an update soon, making some progress here on direction. Thank you for your patience |
Beta Was this translation helpful? Give feedback.
-
What is an alternative for implementing this behaviour using next/image component right now? |
Beta Was this translation helpful? Give feedback.
-
I'm using lh3.googleusercontent and those URLs accept a load of image options: https://github.com/votemike/lh3-googleusercontent-url-builder/blob/main/index.d.ts |
Beta Was this translation helpful? Give feedback.
{{editor}}'s edit
{{editor}}'s edit
-
Currently next/image only supports next-gen images such as WebP via Accept header, because there's no way to handle fallback for old browsers. This means that image hosts or CDNs that only support changing format based on the URL cannot safely deliver next-gen formats. It also makes it harder to cache images.
The standards-compliant way to do this is to generate a
<picture>
tag with a<source>
tag for each supported format.My proposal would be to keep the default behavior the same: generate an
<img>
tag and use content negotiation in the server for next-gen formats. However we would add a "formats" key to the image config, which could include next gen image formats. The supproted values for these would depend on the handler, and would be justWEBP
by default. If this array was present, then the<img>
tag would be exactly the same, with auto format, but it would be wrapped with a<picture>
tag and would include a<source>
element for each requested type, withtype
attribute containing the mimetype. This would pass an extra "format" option to the handler function when generating the URLs. The default handler would generate these URLs with an additionalf
parameter, which the image server would use to choose a format to generate.This would be fully backwards-compatible, as the
<img>
tag would be unchanged and would still use the auto format, and the<picture>
tag would only be included if theformats
array was included in the config. It would fix issues such as #25136 too.I have worked on a proof-of-concept and would be willing to develop this into a PR if this proposal is approved.
PR: #25683
Beta Was this translation helpful? Give feedback.