It's not everyone, fwiw.  IE doesn't.

Do you have the Mozilla bug #?

https://bugzilla.mozilla.org/show_bug.cgi?id=859640#c21

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2208

Presto sets the value to "null".

WebKit removes the content attribute altogether.

I have previously proposed to adopt WebKit's behavior for reflecting IDL attributes.

> Presto sets the value to "null".

That's not what I see in Opera "12.50 internal"....

For what it's worth, I think WebKit's behavior here is what authors tend to expect in my experience...

(In reply to comment #5)
> That's not what I see in Opera "12.50 internal"....

That's an old build. "12.50" was renamed to 12.10. I tested the currently shipping version, 12.15.

> For what it's worth, I think WebKit's behavior here is what authors tend to
> expect in my experience...

I agree.

That's bug 17283.

Note that removing the attribute in Gecko makes the <img> stop rendering, whereas in WebKit, removing the attribute or setting it to "" doesn't do anything. (Gecko is per spec here, WebKit is way not.)

I'd be curious to know for these tests what IE does, (a) in the DOM, and (b) in the rendering:

   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2208
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2210
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2211
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2212
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2213

IE matches Gecko on all those tests.

As far as I can tell, the spec is correct here, and matches Gecko and IE.

Note, in particular, the difference between these two, which gets to the core of what this bug is about. As far as I can tell, only WebKit-derived browsers act different than the spec:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2208
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2273

So I don't see why this is a bug.

> As far as I can tell, the spec is correct here, and matches Gecko and IE.

It doesn't match Gecko up through Gecko 19.  Again, we recently changed the behavior here, as part of conversion to WebIDL, and had reports of web compat regressions.  We are strongly considering switching back to the old behavior as a result.

Do you have any links to examples of breakage other than this one?:

   https://bugzilla.mozilla.org/show_bug.cgi?id=859640#c21

If that's the only one, it doesn't seem very compelling — it looks like "just" a performance regression, caused presumably by the page waiting for the 'null' URL to load, something which is trivially fixed in the markup (remove the call to set the 'src' attribute), something which might easily happen since the person who reported it appears to be the site maintainer. The change requested here is unusual (it makes this attribute act like few others).

To recap:
 - no actual breakage, just slower
 - site owner is aware of problem
 - author-side fix is easy
 - no other known regressions
 - spec behaviour is more consistent than old behaviour
 - no broad agreement amongst browsers

I'm not "being unresponsive"; I looked at the data provided, and I couldn't find any compelling reason to do what was suggested. There doesn't seem to be a strong compatibility case one way or the other here. If you want a spec change that doesn't match all the browsers, you need to give me a strong reason, especially if your desired behaviour is an unusual one.

I honestly no longer have the energy to worry about either the Gecko or spec end of this.  If we run into more breakage, we'll point it out, but I expect this will simply remain non-interoperable between WebKit/Blink and now Gecko/IE...

Closing per comment 10. If you do find breakage (I wouldn't say "more" breakage since the only known breakage is just a performance regression), or if you find any other compelling reason to change this to the less logical behaviour, please do reopen the bug.