Empty source set should be allowed

[yoavweiss]

While talking to @colinbendell, he mentioned a use case he has: loading certain images only on some viewport sizes, but loading nothing on others.
My response was that this should be possible by eliminating the srcset attribute from that <source>, but it doesn't seem like we specced it that way. Unless there's some other way to answer thzt use case, we probably should.

Can we modify https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element:attr-picture-source-srcset-3 so that a lack of srcset would result in a returned empty source set?

I hesitate regarding 5 there. What should we do if there are no candidates?

[zcorpan]

I think this was intentional to have a story for future extensions.

Can you elaborate on the use case?

[yoavweiss]

As I understand it, the use case would be a Web site where the wide viewport breakpoints includes certain content images that are not present in narrow viewport breakpoints.

So, images that today have a display: none rule on them for certain breakpoints, and are downloaded anyway.

[zcorpan]

Interesting. How about we return empty source set if srcset is absent, but continue the algorithm if srcset is present but does not result in any parsed image sources? That would satisfy the use case and have the same forward compat story.

[zcorpan]

Although since srcset parsing mostly ignores unknown descriptors, it seems like it won't return an empty source set anyway for future extensions to srcset. So maybe we can stop the algorithm when srcset is present also...

[zcorpan]

Another issue here is that if the make the algorithm return an empty source set, I think that will result in an error event being fired and alt text showing up (or broken image icon). I guess that's not quite the wanted result.

[yoavweiss]

Another issue here is that if the make the algorithm return an empty source set, I think that will result in an error event being fired and alt text showing up (or broken image icon). I guess that's not quite the wanted result.

It's probably something authors can live with (display: none the alt text and ignore the error), but it would be better if we could avoid that altogether.

[zcorpan]

Yeah. So what is the ideal behavior? Fire load event? Fire a new event emptied? Should the rendering be display:none? Or like <img alt="">?

[zcorpan]

I think this is blocking on https://www.w3.org/Bugs/Public/show_bug.cgi?id=26702 for a proper fix.

[Wilto]

Ah man, I am super not into the idea of showing/hiding an image completely using picture. I know requests are complicated when it comes to display: none on an image and parents thereof, but we don’t encourage people to strip src off img when they want to hide one. Besides, an image that’s optional at some sizes is likely in “decorative” territory anyway, so it might be a better job for CSS from start to finish—hiding real content “for mobile” is a pretty well established not-best-practice with RWD.

-1 to changing behavior to accommodate this.

[yoavweiss]

I was under the impression that we have discussed it in the past as a valid use case, but maybe I was hallucinating...

I guess that authors can do this by setting the src to some 1x1 transparent GIF, that would expose this as the hack that it is.

[zcorpan]

@Wilto's argument that images that are hidden in some layouts are probably not content images seems compelling. But it's hard to know without having real examples to study.

Moreover, images that are hidden in some layouts seem like they will not be critical in the layouts where they are visible, either, so it should be fine to use lazyload (or whatever when it exists), which will not download anything for display:none.

So lacking examples and the fact that it's easy to work around (don't even need 1x1 GIF, just use data:,x) makes this WONTFIX for now at least.

[yoavweiss]

@aarongustafson - Can you share real-life use-cases for this?

I'd prefer not forcing authors to got through data-URI copy-pasting for valid use-cases.

Reopening, since I think we need to discuss this some more.