Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMP's srcset/sizes is different from browser's native implementation #11575

Closed
kraftpixel opened this issue Oct 6, 2017 · 24 comments · Fixed by #16404
Closed

AMP's srcset/sizes is different from browser's native implementation #11575

kraftpixel opened this issue Oct 6, 2017 · 24 comments · Fixed by #16404

Comments

@kraftpixel
Copy link

kraftpixel commented Oct 6, 2017

What's the issue?

AMP's sizes attribute doesn't work in the same way as a browser's native implementation. AMP-IMG tag doesn't seem to be respecting the width of the element set by SIZES attribute and ends up loading the image based on the entire viewport width.

This was pointed out by our client. The test was done on a desktop browser. This does not happen normally as users will generally only land on AMP pages from a mobile device and these devices generally have a width below 600px. I'am mentioning the issue here just in case it's possible to address this difference.

How do we reproduce the issue?

Please disable caching through 'Developer Tools' > 'Network' tab > 'Disable Cache' then try out the following links on desktop to observe the difference.
Note : sizes="300px" in both the following cases.
Native Implementation : https://codepen.io/KraftPixel/pen/JrMQaJ
AMP Implementation : https://codepen.io/KraftPixel/pen/JrMQpN
For reference : Here is a screenshot of the output on a 1920x1080 -> https://i.imgur.com/g2jFaxu.png

What browsers are affected?

Tested on Google Chrome (Desktop)

Which AMP version is affected?

1506977814714

@aghassemi
Copy link
Contributor

/cc @dvoytenko

@dvoytenko
Copy link
Contributor

@cramforce is this the way you wanted this in the last PR?

@cramforce
Copy link
Member

I did not realize there was the action-at-a-distance of handling the sizes attribute in framework land and srcset on the image itself.

I suppose we could revert to old behavior if the sizes attribute is present on the amp-img element as a quick fix?

I still think that going forward we should just use the native implementation here.

@dvoytenko
Copy link
Contributor

@cramforce I suppose either way. Maybe we should just copy srcset/sizes from amp-img to img and leave the current implementation in place as a polyfill for those that do not support it?

@cramforce
Copy link
Member

+1

@ampprojectbot
Copy link
Member

This is a high priority issue but it hasn't been updated in awhile. Do you have any updates?

1 similar comment
@ampprojectbot
Copy link
Member

This is a high priority issue but it hasn't been updated in awhile. Do you have any updates?

@adelinamart
Copy link
Contributor

Since is a high priority I'm assigning it to you @dvoytenko Feel free to re-assign.

@ampprojectbot
Copy link
Member

This is a high priority issue but it hasn't been updated in awhile. @dvoytenko Do you have any updates?

2 similar comments
@ampprojectbot
Copy link
Member

This is a high priority issue but it hasn't been updated in awhile. @dvoytenko Do you have any updates?

@ampprojectbot
Copy link
Member

This is a high priority issue but it hasn't been updated in awhile. @dvoytenko Do you have any updates?

@tbll
Copy link

tbll commented Jan 27, 2018

Here is an example:

<!doctype html>

<html amp lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
    <style amp-custom>
      img, amp-img {
        width: 10vw;
        height: auto;
      }
    </style>
  </head>
  <body>
    <amp-img src='http://placehold.it/720x440'
      width='720' height='480'
      sizes="10vw"
      srcset="http://placehold.it/360x240 360w, http://placehold.it/720x480 720w, http://placehold.it/1080x720 1080w,  http://placehold.it/1440x960 1440w">
    </amp-img>
    <img src='http://placehold.it/720x440'
      width='720' height='480'
      sizes="10vw"
      srcset="http://placehold.it/360x240 360w, http://placehold.it/720x480 720w, http://placehold.it/1080x720 1080w,  http://placehold.it/1440x960 1440w">
  </body>
</html>

@tbll
Copy link

tbll commented Jan 27, 2018

If I understand correctly, <amp-img> assumes sizes=100vw not matter what. This totally defeat the purpose of <amp-img>. All my amp pages download the highest resolution of my images :(

@amphtml-team
Copy link

amphtml-team commented Jan 27, 2018 via email

@cramforce
Copy link
Member

Sizes should not be ignored. My first change was just bringing it towards native srcset. Lets fix, but primarily lets just use native srcset and be done with it. There are no longer any browser issues. We only need to dynamically create a missing sizes when needed.

@aghassemi
Copy link
Contributor

Logging some offline discussions:

1- We will move to full native support and remove AMP-specific logic from processing srcset
2- We may add a new opt-in to evaluate srcset based on container width rather than viewport width ( useful for cases such as thumbnail grids). This might endup being a "best-effort" and ignored in certain situations (e.g. hero images).

@aghassemi
Copy link
Contributor

/cc @ericlindley-g

@ampprojectbot
Copy link
Member

This is a high priority issue but it hasn't been updated in awhile. @dvoytenko Do you have any updates?

@aghassemi
Copy link
Contributor

so we will either do 2 or 3. Alternative name suggestions:
for (2): sizes-behavior=<native, layout>, use-native-sizes , ??
for (3): native-sizes

@cramforce
Copy link
Member

Any update here?

Not having this is actually a problem for our webpackaging project.

Eventually @twifkak's preload generation needs to mimick the same algorithm.

@adelinamart Lets track this as a dependency for WPK.

@cathyxz cathyxz assigned cathyxz and unassigned dvoytenko and aghassemi Apr 30, 2018
@aghassemi
Copy link
Contributor

@cathyxz has started working on a fix. Thanks Cathy!

@cathyxz
Copy link
Contributor

cathyxz commented May 23, 2018

Just an update on this. We're going to ramp up this experiment on a weekly basis: 1%, 10%, 30%, 50%, 100%. Assuming no P0/rollbacks, we'll have this 100% in production in roughly 4 weeks and I'll cleanup the experiment in week 5. If anyone wants to opt in for testing, this is currently 100% in canary (dev channel), and under the experiment 'amp-img-native-srcset'.

One thing missing here is I think that we need to generate a sizes attribute if it is not present. This generated sizes attribute should select a src from the srcset based on the screen width.

^ I'm tracking this, and will start ramping that up when we're a bit more certain that 'amp-img-native-srcset' isn't breaking anyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants