-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support picture tag in next/image #25683
Conversation
… feat/image-sources
9142d40
to
5aeea02
Compare
Would this work for using a totally different image ant certain size for art direction? |
I was hoping to use the Would this kind of use-case be supported if/when this PR goes through? Here's what I have in mind specifically. The following code works with <picture>
<source
srcSet="https://via.placeholder.com/100/333333/ffffff.png"
media="(prefers-color-scheme: dark)"
/>
<img
src='https://via.placeholder.com/100/dddddd/000000.png'
width='100px'
height='100px'
alt='Placeholder image'
/>
</picture> |
+1 🆙 what's the progress since the PR opened for almost a full year? @ascorbic |
We're exploring options for where to take |
df8579c
to
47e5ebe
Compare
Any updates on this @leerob ? Looks like it's not in next 13 unless i've missed it? |
e078ebe
to
6b863fe
Compare
@ascorbic This will screw up pseudo-classes like |
Update: We have extracted the core logic from This allows usage outside of
Exampleimport { 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 |
Feature
fixes #number
Feature request: #25393
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.This PR keeps the default behavior the same: it generates an
<img>
tag and uses content negotiation in the server for next-gen formats. However it adds a "formats" key to the image config, which can include next gen image formats. The supproted values for this depends on the handler, and would be justwebp
by default. If theformats
array is present, then the<img>
tag would be exactly the same as 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. These 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.The server implementation adds an optional
f
param, which if set to a valid next-gen image format (i.e. WebP), then returns that format, ignoring accept headers.This is fully backwards-compatible, as the
<img>
tag is unchanged and still uses the auto format, and the<picture>
tag would only be included if theformats
array was included in the config.I have included an implementation of the component and the server, integration tests for both, and docs. I have not included telemetry (because I'm unsure of the best way to add it).