For example, if you have an img and you do:

  img.crossOrigin = img.crossOrigin;

does that update the image data?

What about:

  img.src = img.src;

?

Note that I believe it's a web compat requirement that the latter do so (at least to the extent of resetting GIF animations) but it would be nice if the former did not.

Oh, and I bet whether "update the image data" runs is observable via load events on the image or something, not just via whether the image data changes.  :(

The spec says:

# A user agent that obtains images immediately must synchronously update the image 
# data of an img element whenever that element is created with a src attribute, a 
# srcset attribute, or both. A user agent that obtains images immediately must 
# also synchronously update the image data of an img element whenever that element 
# has its src, srcset, or crossorigin attribute set, changed, or removed, and 
# whenever that element's adopting steps are run.

Is that sufficiently clear?

I'm not sure it is.

Specifically, consider this case:

  img.setAttribute("src", img.getAttribute("src"));

Is that the attribute being "changed"?  If not, is it being set?  If yes, then why does the spec draw a distinction between "changed" and "set"?

Specifically, if the usage of "set" and "changed" here refer to http://dom.spec.whatwg.org/#attribute-is-set and company then we should not be mentioning "changed" at all?  All we want from there is "set" or "removed".  If we're not using those terms, then we should define the terms we're using.

And again, that would imply that setting .crossOrigin to its existing value reloads the image, which seems suboptimal...

Oh, and one other related thing: Gecko updates the image data differently on src sets and other changes (e.g. src sets force a cache validity check even if the URI did not change)...

...and I seem to recall the web depending on that.

From http://www.whatwg.org/specs/web-apps/current-work/#dom-trees :
# A content attribute is said to change value only if its new value is
# different than its previous value; setting an attribute to a value it
# already has does not change it.

OK, but the use of "changed" here doesn't link to that definition, and the DOM uses a different one.

Can you see why I was being confused what the spec was requiring yet?

And again, setting src to its existing value should not be a no-op last I checked.  One of the few exceptions.

I agree that the prose is confusing (though it long predates the DOM spec).

Setting the IDL attribute:
  http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2874
  http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2875

Setting the content attribute:
  http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2876

Firefox doesn't reset the animation, as far as I can tell.

> Firefox doesn't reset the animation, as far as I can tell.

Firefox 27 regressed this, along with some other src setting stuff.  Try Firefox 26 or earlier...  See <https://bugzilla.mozilla.org/show_bug.cgi?id=980243>.  Fixing that bug is what prompted me to look at this part of the spec, btw.

Ah, good to know. Thanks.

Run 'update the image data' for img.src = img.src case.
https://github.com/ResponsiveImagesCG/picture-element/commit/56512126f8ac4d69f58807df6b6cfe6d7df20ccb

Make img.src = img.src restart the animation.
https://github.com/ResponsiveImagesCG/picture-element/commit/d2888fb80c2b35070034a6c3ad5cf90a889d955f

Hixie, please move the "restart the animation" definition to the Rendering section. Thanks.

Done; back to you to remove the relevant paragraph in the <img> section.

Checked in as WHATWG revision r8725.
Check-in comment: Move 'restart the animation' down
http://html5.org/tools/web-apps-tracker?from=8724&to=8725

https://github.com/ResponsiveImagesCG/picture-element/commit/9c3de000b48dc8181fd7564f9ccea99a927668ba