Discussion: Allow lazy-loading img element

[cramforce]

Chromium recently shipped the loading=lazyattribute for img and other browsers seem to be on track to gain support as well.

With that, I'm wondering if we are ready to make image elements of the form

<img 
    loading=lazy 
    decoding=async 
    width=$width 
    height=$height 
    src=… 
    srcset=…
    sizes=…>

valid?

CC @Gregable @dvoytenko

[Gregable]

@honeybadgerdontcare

[Gregable]

I assume this is only in <noscript>?

[sparhami]

We added support for these in noscript images in #23765.

In addition to loading="lazy", we would want to require using intrinsicsize to ensure layout stability, otherwise we could only support fixed/fill layouts.

[cramforce]

@Gregable Nope, specifically outside of noscript. It would requires rewriting of src/srcset to the AMP Cache like on amp-img, of course.

The thesis is basically: If the native image element behaves like we want it to, then we should allow it.

@sparhami We don't want to require it, I think. But we should allow it. Unfortunately the spec discussion on intrinsicsize hasn't conclusively ended yet.

[jridgewell]

I think intrinsicsize is dead.

[Gregable]

Ah, ok.

Would this need any special handling for layout attributes? Lightbox-gallery? Would we also want to allow in <amp-list> templates?

[cramforce]

Let's start simple. But autolight-box is a good point to consider. CC @nainar We should probably catalogue all features of amp-img and see which ones

• are supported by new attribute
• can be progressively enhanced without a custom element
• aren't important enough to keep

[cramforce]

Another point on intrinsicsize: If we require width and height folks can still make responsive images, just using the old padding-top hack. If there is a nicer platform solution that can just be added.

[nainar]

@alanorozco for auto lightbox.

[dvoytenko]

I think if we have lazy support and unsized media feature policy - we could allow native img. Before then - it doesn't solve our key requirements yet.

[cramforce]

@dvoytenko If we require width and height we don't need unsized media policy, right?

[dvoytenko]

That's true. As long as they are both specified and both are valid numbers.

[cramforce]

Yeah, we still have the validator. That is why we don't need the browser policy.

[cramforce]

Although I could also see to require application of the policy in meta tag and then not requiring width and height.

[dvoytenko]

@cramforce I think we can definitely start with width and height as you suggested above. Supporting unsized media policy would go much deeper with more validator changes.

[cramforce]

It seems that consensus is now moving towards inferring aspect ratio from width and height attributes (the same thing that AMP does) https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/hbhKRuBzZ4o/pmehGGHKAAAJ

One difference compared to AMP is that if those values are wrong, things will still jump. That is definitely a reason to concern. E.g. width=1 height=1 on every img would be valid, but jumpy.

[dvoytenko]

@cramforce Yeah. That would take a metric to report and resolve.

[cramforce]

I'm actually not 100% certain my interpretation is correct. I'll ask on the blink-dev thread.

[cramforce]

OK, this was clarified. Current intent is to give the image priority, so this would be a jank vector.

[alanorozco]

RE: auto-lightbox, we would only need to change how the extension scans. We also might need to change how lightbox-gallery scans and picks images.

[dvoytenko]

@cramforce Do we have any concern that loading=lazy might break preloading guarantees if we ever allowed non-cache src for images on cache?

[cramforce]

We couldn't allow those,

On Mon, Sep 16, 2019 at 11:26 AM Dima Voytenko notifications@github.com wrote:

@cramforce https://github.com/cramforce Do we have any concern that loading=lazy might break preloading guarantees if we ever allowed non-cache src for images on cache?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ampproject/amphtml/issues/24233?email_source=notifications&email_token=AAAV4TYNQ7NGRXGUN73MSILQJ7FV7A5CNFSM4IQHDL62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62CEWY#issuecomment-531898971, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAV4T3RTMJG3B27E7BQCQ3QJ7FV7ANCNFSM4IQHDL6Q .

[westonruter]

Aside: Allowing img[loading=lazy] would also open the door to allowing the picture element. This would be helpful for serving existing web content in AMP since it can be difficult/impossible to translate picture into amp-img. We've tried in the context of the AMP plugin: https://github.com/ampproject/amp-wp/issues/1316.

[cramforce]

Closing in favor of #29786