21668 2013-04-11 18:50:36 +0000 .src needs TreatNullAs=EmptyString. Gecko tried without and got at least one breakage report on nightly and everyone does EmptyString today. 2013-10-25 15:15:35 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#htmlimageelement P3 normal Unsorted 1 contributor ian annevk bzbarsky ian kennyluck mike zcorpan contributor oldest_to_newest 85956 0 contributor 2013-04-11 18:50:36 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html Multipage: http://www.whatwg.org/C#htmlimageelement Complete: http://www.whatwg.org/c#htmlimageelement Comment: .src needs TreatNullAs=EmptyString. Gecko tried without and got at least one breakage report on nightly and everyone does EmptyString today. Posted from: 207.218.72.65 by annevk@annevk.nl User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130402 Firefox/23.0 85957 1 bzbarsky 2013-04-11 18:52:37 +0000 It's not everyone, fwiw. IE doesn't. 85958 2 ian 2013-04-11 19:30:21 +0000 Do you have the Mozilla bug #? 85960 3 annevk 2013-04-11 19:46:58 +0000 https://bugzilla.mozilla.org/show_bug.cgi?id=859640#c21 85961 4 zcorpan 2013-04-11 20:34:07 +0000 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. 85962 5 bzbarsky 2013-04-11 20:36:43 +0000 > 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... 85968 6 zcorpan 2013-04-11 21:45:45 +0000 (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. 86143 7 ian 2013-04-13 17:37:58 +0000 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 88590 8 ian 2013-06-03 23:11:02 +0000 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. 88601 9 bzbarsky 2013-06-04 01:54:54 +0000 > 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. 89425 10 ian 2013-06-17 22:32:47 +0000 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. 89441 11 bzbarsky 2013-06-18 02:08:45 +0000 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... 90141 12 ian 2013-07-02 21:14:48 +0000 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.