## 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
In the `noscript` img version the correct `src` and `sizes` attributes are overwritten by not necessary inline declaration; in particular using the loaders the `src` attribute not take the right absolute path. I found this issue using a custom loader and because my site didn't indexing any images on the Google image search.
Fixes#24277
Previously, we had an arbitrary delay of 1500ms but instead we can wait until decoding is complete.
Co-authored-by: Kristóf Poduszló <kripod@protonmail.com>
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
If you give a Static Image to the Image component, TypeScript will throw a type error. This Pull Request fixes it.
## Bug
- ~~Related issues linked using `fixes #number`~~
- [x] 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~~
---
follow-up #24993
cc @atcastle
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)
When using `sizes`, [`matchAll`](https://caniuse.com/mdn-javascript_builtins_string_matchall) isn't supported by older browsers like IE and Safari 12. This PR changes it to `exec`.
There're already tests of `sizes` with multiple `vw` values covered.
Fixes#23677.
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] 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.
- [x] 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
This is a follow-up PR of #19052, where `visibility: inherit` was mistakenly added back. It was removed in #23278.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] 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
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 if you have `sizes` set in `next/image`, the image will likely be downloaded multiple times (usually twice) on Safari (macOS and iOS): the correct size for the viewport, and the original size specified in `src`.
Also make sure you have "Ignore Resource Cache" disabled in the Safari Devtools when trying to reproduce:
The root cause is the way Safari handles `<img>`'s attribute updates. Although React updates all the attributes one by one synchronously and programmatically, Safari will still try to fetch the resource immediately and won't wait for other DOM changes to be finished.
That means if we set the following 3 attributes in this order: `src`, `srcSet`, `sizes`. Safari will fetch the image when `src` is set. And then once `srcSet` is there it will fetch the resource again based on it. And finally, when `sizes` is updated it might correct the resource URL again.
So the fix here is simple: by just reordering those to `sizes`, `srcSet`, `src`, it will only load the image with the correct size only once:
<img width="1498" alt="CleanShot 2021-03-09 at 21 05 30@2x" src="https://user-images.githubusercontent.com/3676859/110477852-a27c7700-811e-11eb-88dc-d6e7895f67bd.png">
Fixes#19478.
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 is a #19325 reconfigured to support a loader passed in via a `loader` prop on the Image component, rather than using a config-based approach.
The idea is that applications wanting to use a custom loader will create a wrapper element for the image component that incorporates that loader. See a simple example of this pattern in the integration tests.
This solution is similar to the one prototyped by @ricokahler in #20213 and described at https://github.com/vercel/next.js/issues/18606#issuecomment-720149156
---
Closes#19325Fixes#18606
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)
Fixes#18720
This removes image preloading. It doesn't work correctly on any browser other than Chrome (with Chrome's real engine). On all other browsers, it triggers 2x the bytes to be downloaded. The tradeoff isn't worth it here IMO.
Chrome itself should be smart enough to bump an `<img />` tag's priority over other preloads that are script type during the preparse phase.
We can reintroduce this when we don't hurt non-Chrome users.
This PR fixes two bugs causing HTML validators to complain.
- Error: Bad value data:image/svg+xml;charset=utf-8, for attribute src on element img: Illegal character in scheme data: < is not allowed.
- Fixed by using base64 for svg during `layout=intrinsic` to avoid angle brackets
- Error: Element img is missing required attribute src.
- Fixed by using base64 transparent gif for `loading=lazy` placeholder
Fixes#18850
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
This PR prints a pretty error when the Image `src` property is a [protocol-relative URL](https://www.paulirish.com/2010/the-protocol-relative-url/).
> Update 2014.12.17:
> Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.
Fixes#18536
