padding-bottom not calculated correctly

Thank you.

Looks like 2 obvious regressions.

One here:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/js/blazy.compat....

// Update multi-breakpoint fluid aspect ratio, if any.
    if (els.length) {
+    $.each(els, updateRatio);
      me.checkResize(els, updateRatio, doc);
    }

Last one:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/js/blazy.compat....

// Bail out if a static/ non-fluid aspect ratio.
   - if (!ratios) {
  + if (!Object.keys(ratios).length) {
      fallbackRatio(cn);
      return;
    }

You may want to minify it into its min.js file.

I am not handy now. Just reading the obvious misses, might be wrong :)

Does that fix the issue?

Attached to address the 2 mentioned regression issues.

The rest are non-committed local works aka bonuses, refinements, and attribute fixes.

FYI, Blazy 2.6+ has already decoupled lazy-load scripts, if any lazy basic issues you can always enable No JavaScript option to behave like core lazy, instead. Only disabled when you need to support old browsers which can be toggled as needed. Aspect ratio, to fix reflow, might be no longer relevant when the image has dimensions set.

Let's make scrolling at tests behave more like human.

I can't think of any other reasons why it failed, certainly not with real browsers.
But likely the reason for the failing test was the end of body was too tall (filled in by Drupal json and script elements) causing the Intersection Obsever never feels it intersects images.

If still fails, something else breaks it.

Forgot we were on headless.
Let's see if still an issue.

We still need to refine the scrolling behavior to correctly reach the target element.

Figuring out the problem one at a time.

Reverted tests to verify stupidity is somewhere else.

Fixed for CS.

Feel free to re-open if still an issue.

FYI, in case the printed aspect-ratio numbers trick you:

• Numbers as read server-side on window[onload|resize]. These basically provide a frame to minimize reflow issues before the image is actually loaded.
• Numbers as read after the image is fully loaded/ decoded. This will correct any server-side limitation into actual natural dimensions.

Most likely they differ slightly given various window sizes. Yet, the object-fit: cover behaves almost similar to background-size: cover;. Meaning as long as blazy.css is in place, and the correct aspect ratio applied, images are hardly distorted.

Addition to "Aspect ratio, to fix reflow, might be no longer relevant when the image has dimensions set", as long as the SRC image is not as a placeholder. Once a placeholder, via old data-SRC|SRCSET|LAZY, aspect ratio should be used.

A note to myself for my future me since this type of failing tests repeat: isolate!

Thank you for contribution.

Ok, I'd love to reproduce it :)

More details are required to narrow down:

• Is blazy.css loaded on the page? Disable aggregation for minute. CTRL + U and search for blazy.css.
• Could you try using it without Views, at regular field UI? Any difference?
• Please press F12, find Console tab, and screenshot if any errors.

Let me know.

Please also save one of your trouble page as static HTML. Upload it somewhere, or zip it, and PM me the link via my Drupal contact form.

So it doesn't disrupt your production, and I can reproduce it. If you keep turning it off, I may not be able to see the problem.

>> Could you try using it without Views, at regular field UI? Any difference?
> It works when I use it directly in the manage display of the content type image field.
Ok, so it works fine at Field UI, but not Views rewrite UI.

I think this is part of the known issues:
https://www.drupal.org/project/blazy#blazy-known-issues
https://www.drupal.org/project/slick_views#slick-gotchas
"Having trouble with Views Rewrite results? Check this out. Shortly putting Blazy/ Slick formatters within Rewrite results box will break _only if using Aspect ratio fluid. Solution: use any alternative aspect ratio, except fluid. Added JS solutions at D8 2.x and D7 3.x branches."

Likely the provided solution kicks in late.

However I've seen your zip, and I see "no evil" :)
Please see attachments, and let me know your expectations. Watch out the file names, and A, B, C.

• A. I forced applying the same padding to all. Solution at your end, choose similar cropped image styles, not scaled pictures.
• B. I forced Aspect ratio 1:1 to all. Solution, choose fixed aspect ratio. The easiest, no crop needed.
• C. Original as seen at first load and refresh. Your image styles are scaled, not cropped. Consequently they differ in height when scaled.

At all cases I see no distortion.

If A and B are expected, consider the provided solutions.

I also notice "zoom in" animation using inview.js file which has errors. Try disabling this for a moment.

Uncaught TypeError: i is undefined
    <anonymous> .../inview.min.js:7

Not sure if this zoom in effect shared the problem, but isolating one by one will help you.

Let me know if I should delete the uploaded screenshots. I removed anything else but pictures to show the problems.

Ok, thanks for the follow up. Glad we are on the same page :)
Setting it back to OP issue.