Allow <picture> element

[ChrisJohnNewton]

Description

With amp-img deprecated, allow HTML's picture element too.

This would be useful so that those who use img over amp-img have a way to use different sources/fallback images without having to resort back to using amp-img.

Alternatives Considered

Improve amp-img fallback to allow it to safely contain multiple fallback images of different image types without browsers downloading more than one working image. For example, I find that Microsoft Edge browser will unnecessarily download multiple fallback images from amp-img even though the first image worked.

Additional Context

No response

[erwinmombay]

@powerivq and i talked a little about this last week. @powerivq are there are downsides or privacy or security concerns in allowing for the picture element?

[ChrisJohnNewton]

Nice to hear there's been some discussion and I'm looking forward to see if this is implemented! The <picture>element works really well in browsers in 2023 so I'm quite eager to use it.

[powerivq]

Proposed example of permissible picture tag

<picture>
  <source media="(min-width:650px)" srcset="img_pink_flowers.jpg">
  <source media="(min-width:465px)" srcset="img_white_flower.jpg">
  <img src="img_orange_flowers.jpg">
</picture>

Background In the earlier versions, AMP mandated use of an amp-img element to display images. The element incorporates essential features necessary for optimizing image loading and rendering in AMP pages. It automatically handles responsive layout and ensures that the appropriate image size is delivered based on the device's screen dimensions. Additionally, it implements efficient techniques such as lazy loading, preloading, and progressive loading to further enhance performance and minimize the impact on the page load time.

Then, with mainstream browsers’ adoption of lazy loading features, among other things, in the native img tags, AMP allowlisted the native img tags. There was a proposal to deprecate amp-img (https://github.com/ampproject/amphtml/issues/30442) since it would appear that amp-img can be substituted with the native img tags in all capabilities.

Picture elements, while offering similar functionality, are not currently allowlisted in AMP. They are also widely used by non-AMP web developers because certain features (e.g. art directions) are only supported on the picture tag, but not img tag. An external collaborator proposes (https://github.com/ampproject/amphtml/issues/39172) to relax the AMP validation rule to permit use of picture tags. Since the picture tag offers more delicate control over which image resource is best, if used correctly, it could lead to better performance than using img tag.

Considerations Privacy In pre-rendering context, AMP must ensure that no external requests (e.g. img tags pointing to the publisher domain) are made from the browser. This ensures that the publisher would not know, by way of analytics, whether a page is being pre-rendered, until and unless the page transitions from pre-rendering context.

Currently, it is implemented on AMP Viewers (e.g. Google Viewer) by converting the URL into an AMP cache URL, preventing the source server from receiving the request directly. Allowing picture elements will require similar conversion to be done on the viewer. Performance best practices One of AMP’s goals is to enforce use of best web engineering practices to render web pages fast, especially on mobile devices. Using amp-img allows the AMP runtime to prioritize content on or close to the viewport, and defer those that appear further below.

Browser-level lazy loading support for the img tag is getting better. It is now supported by all major browsers on desktop and mobile (Chrome 77+, Firefox 75+, Safari 15.4+) However, there is no browser-level support for lazily loading picture tags. Layout shifting Layout shifting causing content to move without user interaction causes bad user experience, and this is what AMP designed to prevent. CLS is also part of the core web vital metrics. To achieve this, amp-img tag requires sizes to be set so that the box size of the image container can be calculated prior to the image being downloaded.

We must ensure that, to the extent possible, allowlisting img tags and picture tags would not cause widespread layout shifting by requiring dimension attributes (height and width) to be set. However, it is not perfect. Height and width attributes are merely browser hints, and the final size can still be changed if the downloaded is different. Malte has suggested using aspect-ratio CSS to cut down abuse (setting height and width to arbitrary value like 1s). Unfortunately, as of Oct 2023, it is still not useable in Chrome. Adoption/Adaptation cost Publishers might already be using picture elements on their non-AMP site. Allowing the same HTML codes to be used without change would make adoption easier, and reduce the long-term maintenance cost.