Some users reported false hits when using complex loaders that implement Art Direction.
We can relax the warnings so that query string params named width should not warn.
This will ensure an image hashed consistently regardless of how its imported:
- `import file from "./file.png"` -> /_next/static/media/file.12345678.png
- `url(./file.png)` -> /_next/static/media/file.12345678.png
- `new URL("./file.png", import.meta.url)` -> /_next/static/media/file.12345678.png
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
As a follow up to #30041 which changed `<div>` to `<span>`, this PR makes sure that unexpected styles are not applied to the image wrapper or sizer spans.
For example: `.content span {}` would apply to all spans and incorrectly style the image wrapper.
This PR adds [`all: initial`](https://developer.mozilla.org/en-US/docs/Web/CSS/all) to effectively reset the span styles.
Bump `squoosh` to the latest version, currently commit [cad09160](cad09160b6).
Ideally, we would use the version published to npm but it hasn't been published in [two months](https://www.npmjs.com/package/@squoosh/lib?activeTab=versions) and we have a patch (#23565) that isn't available upstream.
This also is a precursor to getting support for AVIF.
- Fixes#27092
- Fixes#26527
- Reapplies the patch from #23565
This PR does a few things:
- Moves `<noscript>` usage below the blur image since so that the `<noscript>` image renders on top of the blur image
- Remove the `isVisible` check for `<noscript>` since we can't rely on client-side JS
- Add `loading=lazy` to the `<noscript>` image to take advantage of native lazy loading (can't rely on JS lazy loading)
Fixes#28251
This PR resurrects #23622 which has not been updated in a while. Makes the `Image` component handle `blob:` object urls.
closes#23622fixes#19291
credits: @sdn90
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
We've never supported the `style` prop as seen in the docs https://nextjs.org/docs/api-reference/next/image#other-props
TS users already get a build error but JS users were left in the dark.
This PR adds a warning so its clear during `next dev`.
We shouldn't be setting `placeholder=blur` styles when JS is disabled because we'll have no way to know when the image is loaded and it will be stuck in blur permanently as mentioned in [this comment](https://github.com/vercel/next.js/pull/19052#issuecomment-882886068).
This PR avoids blur styles on the `<noscript>` version of the image.
fixes#26607
This change makes it so the image loader plugin only emits a file while processing an image import for the client. The final generated image URL was already the same in SSR and CSR anyway, so this change doesn't have any functional impact.
I also changed the name of the static page in the image component tests, since it was causing some conflicts with the static assets folder.
This adds a new prop, `onLoadingComplete()`, to handle the most common use case of `ref`.
I also added docs and a warning when using `ref` so we recommend the new prop instead.
- Fixes#18398
- Fixes#22482
## Bug
- [x] Related issues linked using `fixes #26135 `
- [x] Integration tests added
fixes#26135
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #26135 `
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
There are strict conditions for using `placeholder=blur` documented in #25949 but this will give the user a better understanding during `next dev` and links to the error.
- Error when `placeholder=blur` and no `blurDataURL`
- The Error for small images with `placeholder=blur` has been changed to a warning
- Added support for blurring a webp image
- Added error page linking to relevant docs
* Add delay to placeholder removal
* Increase jest timeout for image tests
* Use check instead of immediately expecting the result
Co-authored-by: Tim Neutkens <timneutkens@me.com>
Previously we were accepting a `s=1` query string parameter for static imports, but this is not necessary.
Instead, this PR looks at the file path to determine if the header should be `immutable`.
The nice thing here is we don't need to worry about someone trying `s=1` with an external image or 3rd party loader. In that case, we use the upstream `Cache-Control` header as usual.
This change also ensures we don't add the `immutable` header for `next dev`.
Related to PR #24993
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tim Neutkens <timneutkens@me.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* Remove deprecated features
In the next major version we'll want to merge this PR that removes some of the long-time deprecated features, it'll have a positive effect on bundle size.
* Update tests
* Update tests
* Change unsized to layout=fill in test
* Update sizes
* Update rotation test
* Update size limit test
* Update test
* Update test
* Update test
This is the image component implementation of the blurry placeholder as described in #24004. The matching server side implementation is currently planned.
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issue #18858
- [x] Integration tests added
(Documentation and telemetry to follow after server side is implemented)
The current `<Image />` component does not fallback gracefully when JavaScript is disabled in the client / browser.
You can test this with the [official Next/Image example](https://csb-4k0kr-p8ya8f304.vercel.app/), by disabling JavaScript in the browser's DevTools. Video demo: https://streamable.com/frkvw9
This PR aims to fix this behaviour by using `<noscript></noscript>` tags to conditionally display a standard `<img>` element using the `props` passed to `<Image />` when JavaScript is disabled.
For browser sessions where JavaScript is enabled, this will not cause an increase in network requests, so there should be no downside.
One area where this PR is a bit "hacky" is that it uses a negative `margin-top` to counteract `sizerStyle.paddingTop`. From what I can tell, `sizerStyle.paddingTop` is generated on the server side, where we can not know ahead of time whether JavaScript is enabled in the browser - hence why I've opted for this solution.
Fixes#19223Fixes#21214
This PR removes the `visibility` style property change from next/image. It was previously added in #18195 to fix a bug that when no `src` is set, and that bug is not valid anymore as all images will always have `src` (and a fallback too).
It also fixes the problem that screen readers ignore elements with `visibility: hidden`.
Fixes#23201.
## Bug
- [x] Related issues #23201
- [ ] Integration tests added
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
Currently, the image component doesn't handle use of the `sizes` property with `layout="fill"` and `layout="responsive"` very well for small viewports. It will never include sizes smaller than the smallest viewport (640px) in the srcset, so even if you specify `sizes="30vw"` in your image, you have to download the full-viewport-width image on small devices.
This PR adds logic such that if you use `layout="fill"` and include a `sizes` property, the image component will include the full range of image sizes in the `srcset`.
It also includes an optimization where it finds the smallest `vw` value in the sizes value and combines that with the smallest viewport width, and uses that as the floor of the srcset. It does this so it doesn't unnecessarily increase transfer size by including ALL sizes. This is still a conservative optimization--for 95% of cases, taking the _largest_ `vw` size would work, but I don't see a way to do that without breaking a few corner cases.
The case of a sizes prop with `px` values is fixed but not optimized--though generally that case is less of a good fit for the fill or responsive layout anyway.
This PR fixes a bug where we'd accidentally pass-through the user-provided `srcSet` if the image was lazy, just to then replace it when we hydrate.
---
Fixes#19041
This fixes `next/image` to properly ignore inherited styles applied to the `img` tag by a parent element.
Image styling should **always** be done by a wrapper element—not to the image itself!
---
Fixes#19817Fixes#19964
Currently if sizes is not defined, Next.js is setting sizes as:
```
(max-width: 640px) 640px, (max-width: 750px) 750px, (max-width: 828px) 828px, (max-width: 1080px) 1080px, (max-width: 1200px) 1200px, (max-width: 1920px) 1920px, (max-width: 2048px) 2048px, 3840px'
```
This pull request will make sizes be `100vw` by default, which will allow us to download "smaller" images than what's currently happening.
In a demo app I have, the difference is between downloading 488KB vs 1.4MB (in images)
This pull request fixes `<Image />` not updating when new props are passed by removing external DOM mutations and relying on React to do it instead.
As an added bonus, I've extracted the intersection observer from both the `<Image />` and `<Link />` component, as their instance can be shared!
The increase in size is minor (+3B), and actually a decrease for apps using both `<Image />` and `<Link />`.
---
Fixes#18698Fixes#18369
