Amphtml: amp-img handling unknown sizes

[codecreative]

I've been displaying images from a feed where the size is not currently known. From the docs, it states that width and height are required.

amp-img components, like all externally fetched AMP resources, must be given an explicit size (as in width / height) in advance, so that the aspect ratio can be known without fetching the image.

To avoid validation errors the only solution I can think of is a fixed container that scales responsively and contains the image. Is there any official documentation on proposals for handling unknown sized images? Or is there a better solution than this?

Example:
http://jsbin.com/dogosa/edit?html,output

Thanks,
Byron

[cramforce]

The right thing to do is to download the images and get their size.

[dvoytenko]

If this is a flickr feed, I believe there's a way to return the image's dimensions in the feed.

[codecreative]

Thanks for the responses.
The flickr images were just for a demo. The real images I'm dealing with are coming from a feed that we are getting out of AEM. I have a srcset, but that doesn't really give me any good information for height. We can do a server-side lookup per image to find the dimensions, before rendering the amp page, but it seems like that would add quite a bit of overhead and be working against the idea of amp to begin with.

[dvoytenko]

I think the best course of action is to request the origin (e.g. AEM) to provide it. This is very much expected today from image feeds.

[webdados]

I agree that handling images with unknown sizes is very important.

[sonyarianto]

totally agree and AMP (MUST) support the unknown size, imagine for web aggregators service

[cramforce]

It isn't going to happen. What stops you from fetching the image and getting its size on the server? That is what the browser will do eventually – but it will have to do it over a a shitty high latency 2g connection as opposed to your server in a data center with a 10ms ping.

[webdados]

The browser will fetch the image anyway. And only one time.

Webdados
[image: Webdados - Tecnologias de Informação] http://www.webdados.pt/
Tel.: [phone]
Fax: We lost it in the 90s
Email: [email protected]
www: http://www.webdados.pt
Address: Av. da Ponte 100
Pinhal de Frades
2840-167 Seixal
Portugal

On 23 October 2016 at 17:52, Malte Ubl [email protected] wrote:

It isn't going to happen. What stops you from fetching the image and
getting its size? That is what the browser will do eventually – but it will
have to do it over a a shitty high latency 2g connection as opposed to your
server in a data center with a 10ms ping.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/1939#issuecomment-255599524,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGiT5YF8wQ9eTNZNZ1dQd5_oEUQ9wlE3ks5q25DCgaJpZM4HYQdG
.

[cramforce]

Right, but it cannot know the space before fetching it. That is why the
server should fetch it first.

On Tue, Oct 25, 2016 at 11:59 AM, webdados [email protected] wrote:

The browser will fetch the image anyway. And only one time.

Webdados
[image: Webdados - Tecnologias de Informação] http://www.webdados.pt/
Tel.: [phone]
Fax: We lost it in the 90s
Email: [email protected]
www: http://www.webdados.pt
Address: Av. da Ponte 100
Pinhal de Frades
2840-167 Seixal
Portugal

On 23 October 2016 at 17:52, Malte Ubl [email protected] wrote:

It isn't going to happen. What stops you from fetching the image and
getting its size? That is what the browser will do eventually – but it
will
have to do it over a a shitty high latency 2g connection as opposed to
your
server in a data center with a 10ms ping.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
1939#issuecomment-255599524>,
or mute the thread
auth/AGiT5YF8wQ9eTNZNZ1dQd5_oEUQ9wlE3ks5q25DCgaJpZM4HYQdG>
.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/1939#issuecomment-256141648,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeTxmArtk5LaMfoRT-obNMhaHpW-X0ks5q3lGVgaJpZM4HYQdG
.

[davidwhthomas]

How about when one has the "width" attribute, but not the "height" attribute?
i.e a flexible height image, with fixed width.
Is there a way to render the amp-img for that case? thanks.

[cramforce]

You always need to know the aspect ratio.

On Thu, Mar 16, 2017 at 5:49 PM, davidwhthomas [e-mail]
wrote:

How about when one has the "width" attribute, but not the "height"
attribute?
i.e a flexible height image, with fixed width.
Is there a way to render the amp-img for that case? thanks.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/1939#issuecomment-287235874,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT_2X7xDqBFNz--NQxN0W8CdCE8uRks5rmdiIgaJpZM4HYQdG
.

[davidwhthomas]

ok, thanks

[erykpiast]

@cramforce What is the motivation behind the requirement to specify image size ALWAYS in EVERY case? I can image situations when it makes perfect sense but also many others when it doesn't at all.

Suppose you have container with of dynamic but known size, let's say its width and height they both are 1/3 of the viewport (so we have sort of "responsive squares"). Let's say there is one image displayed inside and in the middle of each square (centered with some custom CSS). I don't know exact size nor the ratio of the image but it doesn't really matter as "fixed" container size and centering the image, they both prevent any kind of jumps that may happen when images are downloaded. How specifying size of the image may improve user experience in such case?
Look at this example: http://jsbin.com/yufeci/edit?html

Is there any reason other than jumps prevention, arguing for this very hard requirement?

[cramforce]

@erykpiast You can implement this with CSS within AMP today.

[erykpiast]

Woah, I didn't know that. That's great. Could you point me out some docs or example site?

[cramforce]

See e.g. https://css-tricks.com/almanac/properties/o/object-fit/

Does that make sense?

On Tue, May 9, 2017 at 4:40 PM, Eryk Napierała [e-mail]
wrote:

Woah, I didn't know that. That's great. Could you point me out some docs
or example site?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/1939#issuecomment-300186184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT2hwkPaEqxFvyxzXmYJTALXIYgwcks5r4HrLgaJpZM4HYQdG
.

[erykpiast]

Hmm, not really. I perfectly know how to accomplish this with CSS, that's not the issue. What I mean is that amp-img component, as far as I understand it, requires exact image size and only once you specify it, page is considered as AMP-compilant. Isn't that true?

[cramforce]

I think something like this should work

img {
  object-fit: cover;
}


<amp-img layout=fill width="1" height="1" src="image.jpg"></amp-img>

Might need some tweaking, but both layout=fill and layout=container should be able to achieve what you want. The width and height would be mandatory but ignored.

[erykpiast]

Alright, thank you!

It'd be nice to cover such case in documentation. I'm not sure if you've noticed, but literally all code snippets with amp-img have height and width specified, in one form or another. (https://ampbyexample.com/components/amp-img/, https://www.ampproject.org/docs/guides/amp_replacements, https://www.ampproject.org/docs/reference/components/amp-img)

[cramforce]

If you have a good example working, would you mind posting it here? Agree
that it would be nice to document it.

On Wed, May 10, 2017 at 12:51 PM, Eryk Napierała [e-mail]
wrote:

Alright, thank you!

It'd be nice to cover such case in documentation. I'm not sure if you've
noticed, but literally all code snippets with amp-img have height and
width specified, in one form or another. (https://ampbyexample.com/
components/amp-img/, https://www.ampproject.org/
docs/guides/amp_replacements, https://www.ampproject.org/
docs/reference/components/amp-img)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/1939#issuecomment-300446320,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeT2U8HVKLRqT0wLdcvBmK2ANicBx6ks5r4ZaUgaJpZM4HYQdG
.

[erykpiast]

Well, it turns out my previous (non-AMP) example may be easily adapted: http://jsbin.com/sojidok/edit?html,output

[cramforce]

Assigning for figuring out the best way to document it. Could also go into ABE @sebastianbenz

[bpaduch]

@sebastianbenz - Thoughts on having a working sample in ABE?

[sebastianbenz]

@bpaduch yup - probably worth it's own sample as it's a common enough problem.

[bpaduch]

Cool. Let me know when it's up on ABE, and I'll update amp-img's Tips and Tricks section to mention the example. Oh, and to understand what was going on this discussion, I created a pared down example (demo, code). Not sure if it's useful or not.

[sebastianbenz]

First version:

https://ampbyexample.com/advanced/how_to_support_images_with_unknown_dimensions/

Let me know if I'm missing anything.

[erykpiast]

@sebastianbenz I'd say this: http://jsbin.com/sojidok/edit?html,output. So image isn't stretched but placed in the middle of fixed-size container.

[sebastianbenz]

@erykpiast the fixed-height layout sample achieves the same effect, images aren't stretched either. The difference to your sample is that your sample responsively adjusts the height to maintain the aspect ratio defined by the container. Is this a common use case?

[erykpiast]

The difference of my case is the image isn't stretched at all on any axis. Fixed-height means it's stretched up (or scaled down preserving aspect-ratio) to given vertical size, is that right? My sample is more about that: the image should be displayed in the middle of some fixed-size area, if it's too big to fit, scale it down preserving aspect ratio, but don't scale it up over its original size. No idea if it's common case, though, I have no data.