Amphtml: Intent-to-Deprecate: `amp-img`
Summary
We would like to allow developers who write AMP to be able to use the native html img tag, use transforms to change existing amp-img tags to native img tags and after sufficient time remove amp-img from v0 and make it an optional component.
Motivation
The amp-img component was primarily created in order to allow for lazy-loading of images in amp pages in order to improve page performance. At the time the native html img tag did not allow for this which necessitated the creation of a custom extension.
Today however, the native img tag does allow for lazy loading through the use of the loading attribute. As a result the amp-img extension is no longer needed to achieve the performance improvements for which it was originally created.
Because of this the amp-img extension will need to be constantly updated in order to maintain feature parity with the native html img tag or risk obsolescence.
In the long term we would like to turn down the use of amp-img in new amp documents, instead allowing developers to use the native html img tag with the loading attribute set to lazy in order to achieve these results. This would remove the burden on amp contributors to constantly maintain feature parity and will additionally allow developers to create simple documents without needing to learn the usage of an extra amp extension.
Impact on existing users
This change will allow users to use native img in future development.
Additionally existing AMP documents which are run through transformers will be modified to replace all existing amp-img tags with img tags.
This will cause the following changes to the amp-img features:
Loading placeholder will no longer exist
The blurry image placeholder will need to be implemented with a background image.
The sizes attribute will no longer be calculated automatically.
height and width attributes will be required
The loading attribute will be required and set to lazy. (not supported on IE)
In order to achieve 1:1 visual parity the native images will also require display:block and margin:0 which are both automatically applied by amp-img css.
Examples:
Sizes/Aspect-ratio - https://glitch.com/edit/#!/amp-img-to-img
Blurry Image placeholder - https://glitch.com/edit/#!/amp-img-blurry-placeholder?path=amp.html%3A77%3A21
Alternative implementation suggestion for developers using AMP
Developers will now be able to use native img instead of amp-img.
We will offer developers the following guidance in order to achieve similar functionality that is offered to amp-img
Use loading= “lazy”
The height and width attributes will respect the actual size of the image, this will cause CLS if they are incorrect therefore for the best experience make sure you use the correct width and height.
Use display: block and margin: 0 which amp automatically applies.
When using srcset you must use sizes in addition in order to verify that the appropriately sized image is selected.
Deprecation Plan
Step 1: Allow developers to use native img in valid amp pages.
Step 2: Use transformers to change amp-img to native img
Step 3: Wait
Step 4: Remove amp-img from the module runtime, because all documents in this runtime have passed through a transformer we are guaranteed that they will only have native img
Step 5: Either remove amp-img entirely, or remove amp-img from v0 and convert it into a regular AMP extension.
/cc @ampproject/wg-approvers
rebeccanthomas
All 38 comments
First off, amazing!
What about other replacement tags, like amp-audio and amp-video? I know things are somewhat different there, so curious if that is in scope.
pbakaus
on 1 Oct 2020
Isn't there an existing issue for this? See https://github.com/ampproject/amphtml/issues/29786
westonruter
on 1 Oct 2020
There is an existing issue @westonruter.
The other issue was closed and moved here as the original proposal has changed.
Edit: I was mistaken, but have closed the other issue now as this updated proposal is taking feedback from the last conversation into account.
kristoferbaxter
on 1 Oct 2020
@pbakaus This is the first attempt at moving away from custom elements for features that have been implemented natively at the element level.
Those items you mention are worth looking into as well, but there is more custom behavior present that might delay migration and/or deprecation.
kristoferbaxter
on 1 Oct 2020
I think the main thing that makes amp-img special is that images are cached and hence the privacy aspects of the AMP custom elements aren't needed here. This wouldn't be true (generally) for other elements that loads resources like video
cramforce
on 1 Oct 2020
We will need to update some code in amp-story and amp-story-360 to support this.
amp-story:
amp-storyis not scroll based and relies on the AMP lazy loading strategy foramp-img. It positionsamp-imgit does not want loaded X viewports away, and brings them closer from the visible viewport to trigger their load.amp-storyrelies on theamp-imgtag to monitor the image load and trigger events or even render itself, we should update theseamp-storyneeds to update its validator rules- Tracked here: https://github.com/ampproject/amphtml/issues/30474
amp-story-360:
amp-story-360waits for theamp-imgto be built and loaded, it should also support theimgtagamp-story-360needs to update its validator rules- Tracked here: https://github.com/ampproject/amphtml/issues/30475
cc @ampproject/wg-stories
gmajoulet
on 1 Oct 2020
To echo @gmajoulet point. I believe we also need to update some code in AMP components that handles layout of its children (e.g. amp-carousel)
Based on what I found image lazy load only applies to element below viewport.
https://web.dev/browser-level-image-lazy-loading/#how-does-the-loading-attribute-work-with-images-that-are-in-the-viewport-but-not-immediately-visible-(for-example:-behind-a-carousel-or-hidden-by-css-for-certain-screen-sizes)
zhouyx
on 2 Oct 2020
@rebeccanthomas
The height and width attributes will respect the actual size of the image, this will cause CLS if they are incorrect therefore for the best experience make sure you use the correct width and height.
If I understand this correctly, this represents a significant departure from amp-img. My understanding here is that the height & width in img only inform initial layout, not enforce final layout. With amp-img, the initial dimension layout is fixed, regardless of what file-specified dimensions the image eventually has.
Is there anything available here that would allow us to enforce this layout? Adding image dimensions has been a burden for many publishers, and I can see them being happy to just set <img width=1 height=1 ...> to satisfy validation, but the image still causing CLS issues when it eventually loads.
If we are comfortable about losing this enforcement, I recommend we do not require width/height in validation.
Gregable
on 20 Oct 2020
IMHO we should still require width and height for validation. They are intrinsic data about the image and any recommendation about the layout would be based on these values. The final layout confirmation will have to be left to CLS.
dvoytenko
on 21 Oct 2020
@dvoytenko Do you see anything preventing this rule from just turning into teams setting width=1 height=1 or whatever constants until the file loads? If the validator isn't preventing the poor loading behavior, I would not feel comfortable enforcing the property presence. Let Web Vitals do that.
Gregable
on 21 Oct 2020
https://playground.amp.dev/#share=PCFkb2N0eXBlIGh0bWw+CjxodG1sIOKaoT4KPGhlYWQ+CiAgPG1ldGEgY2hhcnNldD0idXRmLTgiPgogIDx0aXRsZT5NeSBBTVAgUGFnZTwvdGl0bGU+CiAgPGxpbmsgcmVsPSJjYW5vbmljYWwiIGhyZWY9InNlbGYuaHRtbCIgLz4KICA8bWV0YSBuYW1lPSJ2aWV3cG9ydCIgY29udGVudD0id2lkdGg9ZGV2aWNlLXdpZHRoLG1pbmltdW0tc2NhbGU9MSxpbml0aWFsLXNjYWxlPTEiPgogIDxzdHlsZSBhbXAtYm9pbGVycGxhdGU+Ym9keXstd2Via2l0LWFuaW1hdGlvbjotYW1wLXN0YXJ0IDhzIHN0ZXBzKDEsZW5kKSAwcyAxIG5vcm1hbCBib3RoOy1tb3otYW5pbWF0aW9uOi1hbXAtc3RhcnQgOHMgc3RlcHMoMSxlbmQpIDBzIDEgbm9ybWFsIGJvdGg7LW1zLWFuaW1hdGlvbjotYW1wLXN0YXJ0IDhzIHN0ZXBzKDEsZW5kKSAwcyAxIG5vcm1hbCBib3RoO2FuaW1hdGlvbjotYW1wLXN0YXJ0IDhzIHN0ZXBzKDEsZW5kKSAwcyAxIG5vcm1hbCBib3RofUAtd2Via2l0LWtleWZyYW1lcyAtYW1wLXN0YXJ0e2Zyb217dmlzaWJpbGl0eTpoaWRkZW59dG97dmlzaWJpbGl0eTp2aXNpYmxlfX1ALW1vei1rZXlmcmFtZXMgLWFtcC1zdGFydHtmcm9te3Zpc2liaWxpdHk6aGlkZGVufXRve3Zpc2liaWxpdHk6dmlzaWJsZX19QC1tcy1rZXlmcmFtZXMgLWFtcC1zdGFydHtmcm9te3Zpc2liaWxpdHk6aGlkZGVufXRve3Zpc2liaWxpdHk6dmlzaWJsZX19QC1vLWtleWZyYW1lcyAtYW1wLXN0YXJ0e2Zyb217dmlzaWJpbGl0eTpoaWRkZW59dG97dmlzaWJpbGl0eTp2aXNpYmxlfX1Aa2V5ZnJhbWVzIC1hbXAtc3RhcnR7ZnJvbXt2aXNpYmlsaXR5OmhpZGRlbn10b3t2aXNpYmlsaXR5OnZpc2libGV9fTwvc3R5bGU+PG5vc2NyaXB0PjxzdHlsZSBhbXAtYm9pbGVycGxhdGU+Ym9keXstd2Via2l0LWFuaW1hdGlvbjpub25lOy1tb3otYW5pbWF0aW9uOm5vbmU7LW1zLWFuaW1hdGlvbjpub25lO2FuaW1hdGlvbjpub25lfTwvc3R5bGU+PC9ub3NjcmlwdD4KICA8c2NyaXB0IGFzeW5jIHNyYz0iaHR0cHM6Ly9jZG4uYW1wcHJvamVjdC5vcmcvdjAuanMiPjwvc2NyaXB0PgogIDxzdHlsZSBhbXAtY3VzdG9tPgogICAgaDEgewogICAgICBtYXJnaW46IDFyZW07CiAgICB9CiAgPC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KICA8aDE+SGVsbG8gQU1QSFRNTCBXb3JsZCE8L2gxPgogIDxhbXAtaW1nIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHNyYz0iaHR0cHM6Ly9hbXAuZGV2L3N0YXRpYy9pbWcvY2FzZS1iYW5kLWltYWdlLTEucG5nIj48L2FtcC1pbWc+CjwvYm9keT4KPC9odG1sPgo=
This is true today, one can use any value for width and height to get the validator to pass.
Is the concern that for web developers they will not see an issue besides the impact to Web Vitals? If this is the case, does it make sense to recommend using Pixi more within the Validator?
kristoferbaxter
on 21 Oct 2020
It's possible we change the workflow to Pixi. But looking at the current rules that we have. A native <img> can be used when:
- It specifies
loading=lazy - It has an intrinsic size (
widthandheight) or explicit size (in styles).
I'd just stress that (1) without the (2) is even worse for CLS than wrong values.
dvoytenko
on 21 Oct 2020
We could force AMP's current behavior with img {aspect-ratio: attr(width) / attr(height)!important} in browsers that support aspect ratio. That might be enough to disincentivize abuse.
cramforce
on 21 Oct 2020
My understanding here is that the
height&widthinimgonly inform initial layout, not enforce final layout. Withamp-img, the initial dimension layout is fixed, regardless of what file-specified dimensions the image eventually has.
I don't think this is the case? Both of these result in 1x1 elements on the page after it is loaded (without any layout shifting):
<amp-img width="1" height="1" src="https://amp.dev/static/img/case-band-image-1.png"></amp-img>
<img width="1" height="1" loading="lazy" decoding="async" src="https://amp.dev/static/img/case-band-image-1.png">
As I understand, if an author provides an incorrect width & height, there is no CLS concern here at all. The only concern is for oversized-images, no? (And this is a potential issue with amp-img today as well.)
westonruter
on 21 Oct 2020
You need to assume that sizing was overridden in CSS to ignore the width
and height.
On Wed, Oct 21, 2020 at 1:05 PM Weston Ruter notifications@github.com
wrote:
My understanding here is that the height & width in img only inform
initial layout, not enforce final layout. With amp-img, the initial
dimension layout is fixed, regardless of what file-specified dimensions the
image eventually has.
As I understand, if an author provides an incorrect width & height, there
is no CLS concern here at all. The only concern is for oversized-images
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy/oversized-images,
no?—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/30442#issuecomment-713842902,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAV4TYVEYB7QNVVT2U2HRLSL45KDANCNFSM4R6MDTRA
.
cramforce
on 21 Oct 2020
Right. @cramforce I think the simple abuse looks something similar to:
<img loading=lazy width=1 height=1 style="width:auto;height:auto" src=foo.png>
My proposal would mitigate that.
cramforce
on 22 Oct 2020
@cramforce Where does that CSS live? Is that part of the AMP CSS, boilerplate, or something we expect publishers to add?
Gregable
on 26 Oct 2020
AMP CSS
cramforce
on 26 Oct 2020
Will deprecation of amp-img entail that the picture element should be allowed in addition to img? cf. https://github.com/ampproject/amphtml/issues/21912#issuecomment-640908240
westonruter
on 27 Oct 2020
@westonruter I believe, yes, the hope is to eventually allow picture element. But it's currently blocked on implicit aspect ratio support for picture elements (see https://github.com/whatwg/html/pull/5894 and crbug/1137794).
dvoytenko
on 27 Oct 2020
@dvoytenko I'm super sure that is already working. In practice the picture element has no layout of its own and the thing that is actually being rendered is the img element inside of it which has the currentSrc informed by the surrounding picture.
cramforce
on 27 Oct 2020
@cramforce It works for <img> fallback, but not for <source>. And picture allows different geometries for different sources. That's why https://github.com/whatwg/html/pull/5894 is important.
dvoytenko
on 27 Oct 2020
Do we have a timeline/owner for @cramforce's proposal of enforcing aspect-ratio in AMP CSS? I can help making that change if necessary. For context, #30753 is blocked on this.
Enriqe
on 30 Oct 2020
@zhouyx and @rebeccanthomas are who to speak with regarding timing.
kristoferbaxter
on 30 Oct 2020
I created an example page using aspect-ratio as @cramforce suggested and the abuse example provided by @Gregable https://jsbin.com/biveqehoho/2/edit?html,css,output
It didn't work as I would expect.
- Chrome and Firefox reports
aspect-ratio: attr(width) / attr(height)as invalid attribute after I turn on the experiment. I had to switch to actual number to get rid of the error.aspect-ratio: 200/500(I did see MDN documented the usage, so I guess they will support it later) - I verified that the aspect-ratio got applied via the computed styles. However it didn't override the
width:auto height:autoapplied by style. (Same in Chrome and Firefox after turned on experiment)
Any thoughts?
zhouyx
on 5 Nov 2020
Synced with @kristoferbaxter offline on this.
We could apply the aspect-ratio @cramforce suggested in the future once browsers ships support. However based on research today, that didn't help eliminate the issue.
We would still want to support native <img> because we think the performance gain is worth compromising on the potential image size abuse. We are aware that resize of the <img> may lead to CLS, and we rely on developers to provide the correct image size to avoid that.
The alternative solution is to forbid overriding <img> width and height in inline style. However one can still override the width/height via css, and it would be very difficult to enforce that. (I wish I can do width: attr(width) !important 😂 )
Let me know if there's any objection.
zhouyx
on 6 Nov 2020
I think the validator would have a very difficult time avoiding the width/height override in CSS. Certainly inline style is easier to enforce, but as you said, it's trivial to move to stylesheet.
Applying the aspect-ratio in the future is risky as it could break pages that were working before. I don't know how to evaluate that trade off easily, especially at this decision point. We should probably operate with the assumption that we won't implement the aspect-ratio requirement later if not now.
Given this, I go back to my original recommendation: allow img but don't require width/height attributes.
Gregable
on 7 Nov 2020
If we say we rely on publishers providing the correct width and height, I sorta agree that it makes sense to not have validator enforce the width/height.
cc @kristoferbaxter
We will proceed with width/height requirement as first step. It's always easy to remove the requirement.
zhouyx
on 7 Nov 2020
@dvoytenko Let's discuss with Chrome folks how aspect-ratio doesn't override height:auto. @zhouyx Can't you just set height: unset !important;?
cramforce
on 9 Nov 2020
Didn't know that, i can try
zhouyx
on 9 Nov 2020
@zhouyx Could you pls ping me and we can go over https://jsbin.com/biveqehoho/2/edit?html,css,output? I'm not yet sure what's the problem is from the description. height:auto is exactly what allows the aspect ratio to apply.
dvoytenko
on 9 Nov 2020
height: unset !important; override the height set by height attribute as well.
zhouyx
on 9 Nov 2020
If we do it this way, it should probably be guarded by a css-class that allows applies the aspect ratio.
cramforce
on 9 Nov 2020
The blurry image placeholder will need to be implemented with a background image.
I see two potential problems with this:
- Adding placeholders via css background images can result in hitting the inline style size limit of 1000bytes.
- This will increase the overall CSS size of a page. This will be hard to test for publishers as it means they have to validate every single page.
sebastianbenz
on 9 Dec 2020
@sebastianbenz if this background image CSS was excluded from limits would these concerns go away?
kristoferbaxter
on 9 Dec 2020
@kristoferbaxter yes, I think this would be the best approach. This would already be useful right now as it'd allow you to define a placeholder for ssr'd hero images. I've filed https://github.com/ampproject/amphtml/issues/31512.
sebastianbenz
on 9 Dec 2020
See also #30726 (Validator counts SSR-inserted style attributes against style amp-custom max bytes of 75000)
westonruter
on 9 Dec 2020
Related issues
ericlindley-g
·
117Comments
zhouyx
·
60Comments
jpettitt
·
77Comments
jasti
·
50Comments
dvoytenko
·
70Comments
Most helpful comment
IMHO we should still require width and height for validation. They are intrinsic data about the image and any recommendation about the layout would be based on these values. The final layout confirmation will have to be left to CLS.