I noticed that the original file “repeats” itself into the last line of the srcset images: /user/pages/foldername/_DSC4394.jpg 2560w It’s not there in the example in the documentation and Safari/FF also don’t seem to care. When I remove the line in the inspector Chrome downloads another image, but also not necessary the correct one.
@luap, What might be happening is the effect of <picture> on the way the browser selects the image. See MDN docs on <picture>.
Quote from the docs:
The browser will consider each child <source> element and choose the best match among them. If no matches are found—or the browser doesn’t support the <picture> element—the URL of the <img> element’s src attribute is selected. The selected image is then presented in the space occupied by the <img> element
[bold is added by me]
Since you have no <source> element, the browser will always pick /user/pages/foldername/_DSC4394.jpg, which is the value of src attribute.
What happens if you remove the <picture> element?
Note: If you only need responsive images, the <img> element with a srcset will do. <picture> is used for 'art-direction`: serving different (content wise not size) image at different viewport sizes. See MDN intro on Reponsive Images
You said:
I noticed that the original file “repeats” itself […] It’s not there in the example in the documentation
I think it does also in the docs. See below after a bit of formatting:
Interesting! The example from the documentation is also not working in Chrome! I was linking to the doc, but was actually looking & pasting code from this blog-post: https://getgrav.org/blog/retina-responsive-images
The example from the Blog post works in Chrome, from the documentation does not.
Removing the <picture> element also didn’t change anything, unfortunately.
That’s good news, but do you have an idea how to proceed for my project? Note that I am writing my own template and calling page media images and not via “content”.
Can you also reproduce that the same error is happening inside the grav documentation? I see no new downloads when resizing in chrome, but do so in FF.
@luap, It doesn’t matter whether the <img> definition comes from content or Twig. It’s only the generated <img> HTML in the resulting page that matters.
Anyway…
I have dropped your Twig code into Quarks ‘/templates/default.html.twig’ and renamed p.media.images into page.media.images.
Chrome is working as expected.
I have dropped the code from the blog you mentioned into ‘/templates/default.html.twig’
// formatted it for clarity
<img src="/images/cache/sample1x.jpg"
alt="My Responsive Image"
srcset="/images/cache/sample1x.jpg 733w,
/images/cache/sample@2x.jpg 1466w,
/images/cache/sample@3x.jpg 2200w"
sizes="100vw" />
Chrome is working as expected
As a bonus, I added the <picture> element in Twig.
Chrome is loading the right picture, but that is not as expected according the docs from Mozilla Developer Network I referred to before.
By the way, if you start using a wide screen and then making it smaller, you might not see a different image being loaded, because the largest image is already loaded in cache. For all smaller viewports, the large image from cache will simply be resized which is faster then loading a new image.
@pamtbaau Thanks you for your effort. It’s good to know that it doesn’t matter if the code is coming from content or twig.
But I noticed your example html is different to the one I get, by the names of the sizes. Your filenames end with @2x/@3x, not with the width of the image. As far as I understood there are generally (not only in grav) two ways of using srcset: either for providing the same size for standard, x2 and x3 resolutions, or, to provide a bunch of different sizes and then the browser selects the one it wants to choose.
To be more specific: How could I debug my code, what could I try within my template to see where the error comes from (if it’s not a grav issue)?
@anon76427325 I did some more testing and it’s even more strange.
Yes, adding my code to the default.html.twig of a fresh grav install works perfectly fine.
I now noticed, that while increasing the viewport size, chrome downloaded new images, but not all of them. I am building a onepager with different sections (which are pages in the BE). The first image inside each page is always the original file (not correct), the ones after that behave correctly.
This is my entire twig for the homepage:
{% extends 'partials/base.html.twig' %}
{% block content %}
{% for p in page.collection %}
<section id="{{ p.slug() }}">
{# other stuff here #}
<div class="image">
{% for image in p.media.images %}
{{ image.derivatives(320,2720,300).sizes('100vw').html }}
{% endfor %}
</div>
{# other stuff here #}
</section>
{% endfor %}
{% endblock %}
Do you have any suggestion how to further debug?
I also noticed that any max-size above 1520px is not working, is that somewhere more cleary documented than in the doc? It just says
For the moment it does not work inside markdown, only in your twig files.
The reason for the behavior that only the first image of each section was displayed in fullsize, was that, the first image was part of the site’s menu – and there I hadn’t activated any downscaling yet. So it was my mistake.
However, Chrome did handle the image downloading differently than Firefox and Safari. Both of them were downloading the fullsize for the menu and the srcset-downscaled inside each section, while Chrome only took the higher resolution.
