This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the spec only permits changing the loaded image data when @src is modified. It should both permit and require that the data is updated when @crossorigin is modified too.
I'm concerned that this would lead to people setting src="" then setting crossorigin="" and doubling the amount of network traffic. If we don't do this, then they'll quickly realise they have to set it the other way around (since if they need crossorigin, and don't set it, something will break). What reasoning did you have for the opposite conclusion? (I'm certainly open to changing this, just curious what your reasoning was and whether the above changes your mind.)
As a general rule the way a DOM behaves should depend on the current configuration of the DOM. I.e. on the configuration of elements, children and attributes. It should not matter how it got there. This is much more understandable for people. This is especially the case for attribute setters which people tend to think if as state setters, not function calls. Hence, it's very surprising that the order of setting attributes matter. We have very few diversions from this rule. Most of them involve <script> elements where we simply can't undo actions when attributes or child lists are changed. The *only* other case I can think of is changes to base URIs where complexity was vey high and value very low to try to do otherwise (and I'd expect that over time we'll end up adding a lot of that complexity). Additionally, if the crossorigin attribute doesn't affect what image is actually going to be attempted to be loaded that means we'll be carrying around hidden state not exposed to script. In almost every situation where we do that people end up wanting to get at that state. Which leads to more API for us, or more complexity for them when they have to work around not having that state.
I don't think we'll end up with double network traffic ever. Ain most cases I would expect to not have been able to hit the network by the time that the second attribute is set. But I'm curious what bz thinks of the matter.
For <video>, loading waits for a stable state, so it wouldn't matter if crossorigin was set first or last. However, setting crossorigin after a video has already loaded (or changing the src="" of <source>, even) does not change anything (the script needs to call load()). I'm not sure what to do with <img>. It would be nice if it was equivalent to set src first and crossorigin second in the same script. I'm not convinced that setting crossorigin after the image has loaded should reload the image.
Not starting extraneous loads seems like a basic matter of implementation quality... I'm fairly certain that in Gecko there would be no extra loads.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Yeah, fair enough.
Checked in as WHATWG revision r6779. Check-in comment: Make setting <img crossorigin> refetch the image. http://html5.org/tools/web-apps-tracker?from=6778&to=6779
Checked in as WHATWG revision r6780. Check-in comment: Tweak the algorithm for <img> loading to avoid multiple network requests when src='' is set multiple times in a row. http://html5.org/tools/web-apps-tracker?from=6779&to=6780