This test shows that all browsers fire 'load' even if it's the same source:
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2846

(It also shows that Chrome/Safari don't seem to have a "list of available images", which is interesting.)

Marking WORKSFORME. If you disagree, please reopen but with a test case demonstrating why the test above is wrong.

Actually, the test above can be misleading if the load is slow for some reason. Here's a test that has a bigger margin for handling that:
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2848

The test seems right, but I think this is bad for srcset/picture, where you might end up with seemingly random 'load' events even though the image didn't change.

srcset="" doesn't fire 'load' if it doesn't change. There's a separate algorithm for that case.

Yeah, I know, so I guess it's not much of an issue for srcset itself, but for <picture> it's kind of an issue because there are several DOM mutations that trigger these steps. It would be nice to be able to run the steps without side-effect if the selected URL ends up being the same.

A design that uses multiple elements for this is broken exactly because of issues like this. I pointed that out well over a year ago already, when speccing srcset.

I don't understand the problem here.

I disagree that it is broken. It's more complex, I agree, and I pointed that out also, but the fix for this bug is trivial.

The bug is this:

consider <img id=x src="foo.jpg" crossorigin=""> with foo.jpg loaded, then x.crossOrigin = 'anonymous';. This fires a load event but the image is the same.

or <img id=y srcset="foo.jpg 1x"> with foo.jpg loaded, then y.srcset += ' ';.

or <picture><img src="foo.jpg"></picture> with foo.jpg loaded, then a <source> element with no attributes is inserted before the <img>.

Possibly it's not much of a problem to fire load in the above cases, it just seemed unnecessary and an area where UAs could potentially optimize if there were no observable side-effects.

In the crossorigin case, the image might not be the same. You have to redownload it to find out.

In the srcset += ' ' case... I think it's ok to fire 'load' again. After all, you changed the data that impacts the image selection, so you should expect the image selection to run again. If we didn't fire 'load', how would you know nothing had gone wrong during the image selection update?

The <picture> case is misguided and the element shouldn't exist in the first place, IMHO, so I have no particular comment on the specifics there.

(In reply to Ian 'Hixie' Hickson from comment #10)
> In the crossorigin case, the image might not be the same. You have to
> redownload it to find out.

No, the state of the attribute is the same, and the 'update the image data' algorithm uses the state. The steps don't redownload AFAICT.

> In the srcset += ' ' case... I think it's ok to fire 'load' again. After
> all, you changed the data that impacts the image selection, so you should
> expect the image selection to run again. If we didn't fire 'load', how would
> you know nothing had gone wrong during the image selection update?

I guess that's fair enough.

> The <picture> case is misguided and the element shouldn't exist in the first
> place, IMHO, so I have no particular comment on the specifics there.

You can ignore it if you like but it seems it is being implemented...

At a quick glance, https://github.com/whatwg/html/issues/3709 indicates that this was specced to not fire the load event, but browsers do anyway, and we need to fix the spec to match them. Let's consolidate discussion there.