Images should load progressively and be less intrusive on the user. It should be less obvious to the end user that any lazy loading is happening.
Acceptance Criteria
[x] Spinner should be removed
[]
~~Animation should stay. It's important but it should not depend on the loaded class that is added via JavaScript. We should schedule the animation via CSS at the same point that we start loading the image itself. In other words: Insert the image element into the DOM and start the animation (for example: a 0.3 second fade-in animation with a 0.5s delay). Which means after 0.5s the image canvas will fade in whether completed or not. If not completed, the rest of the image will load progressively to the user directly. All which can happen concurrently with scroll events.
~~
* Moved delayed appearance of image to T137874 in a better explained self contained task/bug. This AC mixes different concerns.
[x] Remove the border (and radius) and make the background color @colorGrayLightest
*****
= Original Bug Report(s) from @Krinkle :
Bug 1:
At the moment the lazy-load images implementation is relatively complex. Part of that complexity is various a border, border-box modifications, and background-color/opacity animations.
I assume that this complexity is the reason the implementation also adds the image to the page layout //after// it has completely finished loading.
Normally in browsers, without lazy-loading, an `<img>` is interpreted by the browser as a target canvas on which to progressively render the image data as it comes in.
The browser does this in a way that is friendly with render performance (e.g. no forced re-rendering for every bit of data that arrives, but it doesn't wait for all data to arrive, either).
This means the user sees (parts of) the image even if the download takes a while and/or if the connection is spotty.
I strongly recommend that we either:
* Reduce layout complexity and make the is-visible handler simply replace the placeholder with the target `<img>` (like we do in the Grade C fallback).
* Or; Figure a way to do it in the current layout.
I'm recommending the former and re-evaluate the added value of the CSS animations for a later iteration.
Bug 2:
There are a couple of things we can do to make the lazy loading of images on mobile less intrusive. Meaning that for the user, she/he will not even know that the images are lazy loaded, only in the case of a really slow connection the user will see that, but that's the case even today.
I've been discussing this with @krinkle and I think a couple of things can make the experience for the user more seamless.
== Skip the spinner ==
You get the spinner every time (I think) and the camera on my phone couldn't catch it because the spinner is so fast on fast connection but check this desktop recording. Do you see the spinner?
{F4022295, width=500}
I don't see how the spinner adds any value for the user. I think there should be a wait time before we use the spinner or rather don't use it at all (to mimic the normal browser behavior) and I think @nirzar can help us here about best practice.
== Do not highlight the image area before it arrives ==
The grey background and the border doesn't make any sense if we all agree that we want to make the lazy loading as seamless as possible. Then I think we need to make sure we reserve the space needed for making images fit, and do not highlight where it will be, so it looks the same as default browser behavior.
{F4022361 width=500}