Images in different <source> elements shouldn’t be the same
It seems the image /site/assets/files/1164/st_mi_18-v2.4880x0.jpg shows the same contents as /site/assets/files/1164/st_mi_18-v2.2440x0.jpg does and it has the same aspect ratio and format.
It seems the image /site/assets/files/1164/st_mi_18-v3.2880x0.jpg shows the same contents as /site/assets/files/1164/st_mi_18-v3.1920x0.jpg does and it has the same aspect ratio and format.
It seems the image /site/assets/files/1164/st_mi_18-v1.2304x0.jpg shows the same contents as /site/assets/files/1164/st_mi_18-v1.1536x0.jpg does and it has the same aspect ratio and format.
It seems the image /site/assets/files/1164/st_mi_18-v1.768x0.jpg shows the same contents as /site/assets/files/1164/st_mi_18-v1.1440x0.jpg does and it has the same aspect ratio and format.
The <source> element should only be used for art direction and format-based selection. For providing multiple resolutions of the same image use the srcset attribute instead. More information on CSS-Tricks.
The error report is suggesting that multiple images in the srcset in an individual source should not be of the same aspect ratio/content. I would suggest this is incorrect - I think that the message should only apply to different source images, not srcset images in the samesource element.
Again, I also think there is some confusion because of the different DPR based media queries at the same min-width query values.
Just a heads-up with this, I have written server side code to auto-generate responsive image markup so, some of the markup I am generating is quite extreme and and just testing the boundaries of my code. However, your linter is helping to sanity check my markup! Many thanks :)
They are apparently showing the exact same image in different resolutions which should not be the case for two different <source> items. I think the correct version of these two <source> items combined should look like:
They are apparently showing the exact same image in different resolutions
Take the case you have highlighted. At min-width: 1220px, I want to show an image with a particular aspect ratio and the base image I have selected is 1164/st_mi_18-v2 -- the only difference between the two source elements is that one is for retina and the other non-retina.
I don't want to show a different image/aspect ratio at min-width: 1220px just because one viewer is looking on a retina device and another isn't.
The viewport on both source elements is min-width: 1220px so, I want the same image showing for DPR1 or DPR2+.
Again, I think the linter message is wrong for this reason.
the only difference between the two source elements is that one is for retina and the other non-retina.
I think this is the root of the misconception, you should not create different <source> elements for different DPRs. The browser does this already himself if you just use one <source> with srcset and sizes. Take a look at the srcset Article on CSS-Tricks.
Hmm. I'm not sure it's a misconception! :) The article you refer to is specifically related to srcset and I think in general terms, srcset in the context of the referred article is in the context of img. If fact, the only mention of picture in that article is to say that img does a better job!
When using picture/source, you are telling the browser what you want it to do. In this case, I want it to do certain things on a retina or non-retina screen. However, this use-case at the same breakpoint is semantically the same, hence why I don't think it's correct to fail the test because of the use of the same image/aspect ratio at the same breakpoint that is differentiated by the DPR in the media query.
I'd be very obliged if you took a look at, say, http://www.theguardian.com/international and check any of the images and you will see wholesale use of the same technique that I have outlined here. My interpretation is in use out there on the web and http://www.theguardian.com/international is a highly trafficked site who have placed a very high emphasis on responsive images.
The fact that their image sources are provided by the Imgx service is largely irrelevant inasmuch as they [Imgx] are just an end-point. It is the browser that makes the image request and their use of picture/source is completely server generated.
This is a very interesting discussion and I appreciate your linter and your engagement in this topic! :)
I think in general terms, srcset in the context of the referred article is in the context of img.
srcset and sizes on an <img> work exactly the same as on a <source>, so that shouldn’t make any difference.
I'd be very obliged if you took a look at, say, http://www.theguardian.com/international and check any of the images and you will see wholesale use of the same technique that I have outlined here.
To be honest, I think The Guardian isn’t doing it right, or at least not as <picture> and <source> are meant to be used. E.g. if I zoom out or resize the browser, several different sizes of the same image get downloaded, even if a larger version is already stored in the cache. This would not be the case (at least in Chrome) if they used <img> with srcset and sizes.
I may be wrong with that, but maybe someone from The Guardian (@phamann ?) or a responsive images expert (@zcorpan) can help us to shed light on this?
The markup pattern used here should be allowed I think. The reason one might want this is that for high-DPI displays, you can compress the images harder without losing visual quality. There is currently no way to express that distinction in srcset itself. Also see http://stackoverflow.com/a/31099581/729033 (cc @aFarkas).
That makes sense. Thank you for taking a look at it.
The problem I see with allowing this pattern is that it is still wrong if the high-DPI images are not compressed harder, as happened in this example from @gazley. I’m not sure if it is possible to detect the compression level of an image in the browser via JavaScript.
It's not just about compression as a use-case. I stated that my markup was auto-generated by my server side code. It isn't "real" code at this stage but it's entirely valid for reasons like those suggested by others in this thread. If the images are the same aspect ratio at the same media breakpoint, then there is clearly a user-defined reason for this that is beyond the scope of your linter.
If there were the same image content/aspect ratio at different breakpoints, then your position would be entirely valid. I think you need to consider that with the picture element, the user's desire wins out as long as it is obviously not breaking very clear rules eg: the breakpoint is different but the images are the same content/aspect ratio. That would be clearly wrong and not open to interpretation. However, someone specifying the same aspect ratio and having more than one source element at the same breakpoint differentiated by DPR in the media query is a heuristic that is a no brainer.
In summary, I don't think it's your job to determine or detect the compression level of an image or the reason why someone has decided to do this in the circumstances I am referring to. The scenario I have outlined has been accepted by someone you obviously trust as a realistic use-case and the pattern can be easily detected with the simple heuristics that I have pointed out throughout this thread.
I'm getting a similar issue to this where I am specifying a portrait image for portrait displays and different size landscape images for landscape displays. Here is my code:
If there were the same image content/aspect ratio at different breakpoints, then your position would be entirely valid.
But this is the case in your example from The Guardian. They use the same content/aspect ratio at different min-width breakpoints.
Detecting that <source> is used for art-direction and srcset is not used for art-direction was one of the main reasons for me to create this linter. I don’t like allowing a markup pattern generally that is only correct if the images are compressed differently.
@AMA3 I think your issue is different to this one. Please open a new issue and add a link to the affected page if possible.
The "compression" point was made by a one of the other posters in this
thread and you have picked up on it. I don't think that was one of your
original use-cases.
There is the "theoretical" and there is the "practical" - sometimes the
lines blur and you need you be pragmatic/flexible about it. There are
practical use-cases supporting the pattern I outlined eg: The Guardian.
They aren't fools and I'm certain they would have their own valid points
about why they have used that pattern on their high traffic global sites.
I've already said that my code generation examples were just that -
examples. I'm generating this stuff server-side and I hoped your tool would
help me to ensure that I was more or less on track. The fact that the
images I used weren't compressed in my example is arbitrary. In real use,
they may well be.
I think there is an "exception to the rule" that occurs when you have more
than one source at the same breakpoint that is differentiated by the DPR
media query. I (and the Guardian, and the guy who made the point about the
compression use-case) also think this is the case.
As far as the Guardian goes, if you look at the Url parameters on their
typical image Urls for the higher DPR breakpoint (min-resolution: 120 dpi),
with seemingly the same image as featured in the lower resolution media
media query at the same breakpoint, you will see Url parameters that says
"dpr=2" and "q=20". This tells the Imgix API to serve up a 2x image with a
quality factor of 20.
The low-resolution source at the same breakpoint doesn't specify a "dpr"
parameter (and so the Imgx API serves the image at the default "dpr=1").
However, it does specify the "q" (quality parameter) at "q=55".
In this case, the difference on the higher resolution source is a higher
density, lower quality image. How could your linter possibly know and
understand this third party image API they are using? The answer is that it
doesn't need to, just like I felt that it doesn't have to work out whether
a "normal" image is compressed.
It's the developer's prerogative to use whatever image he/she wants to in
these circumstances ie: same breakpoint/different DPR media queries.
Anyway, this is getting to the point where the "juice isn't worth the
squeeze" :)
You don't agree with me and that's fine. It's your Linter and you can
obviously do what you like with it.
If there were the same image content/aspect ratio at different
breakpoints, then your position would be entirely valid.
But this is the case in your example from The Guardian. They use the same
content/aspect ratio at different min-width breakpoints.
Detecting that is used for art-direction and srcset is not used
for art-direction was one of the main reasons for me to create this linter.
I don’t like allowing a markup pattern generally that is only correct if
the images are compressed differently.
@AMA3https://github.com/AMA3 I think your issue is different to this
one. Please open a new issue and add a link to the affected page if
possible.
The "compression" point was made by a one of the other posters in this thread and you have picked up on it. I don't think that was one of your original use-cases.
The compression use-case is the only one I know (so far) that would make sense of such a markup pattern. I added this now to the sameContent rule, so it will no longer report an error if another <source> uses the “same” images with a high-DPI media query and harder compression.
If you find any other use-case for this markup pattern, please reopen the issue.