This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec currently says to return false and do nothing if value is the empty string. This isn't what IE and Blink do. IE inserts an img with no src attribute and returns true. Blink inserts an img with src="" and returns true. I would like to align Blink with IE's behavior, always returning false seems like a riskier change with no obvious upside.
The spec matches Firefox, so it's presumably web-compatible. It makes much more sense IMO, since <img> and <img src=""> are both useless nodes to have in the DOM, as far as I can tell. Moreover, in the standard use-case for insertImage, the user supplies the URL. If the user supplied an empty URL for their image, correct behavior is to treat it as an error, not insert a broken image. Do you have any particular reason to think the IE/WebKit/Blink behavior is significantly more web-compatible than the Gecko behavior? If not, I'd go with what makes more sense. (Note that the editing spec is not maintained right now, due to lack of implementer interest, so it won't change regardless, unless someone wants to take it over.)
Blink now matches IE's behavior, since aligning with IE allowed the behavior of execCommand("insertImage") to stay the same when I changed the default arguments of execCommand to match the spec. I have no reason to think that there's much Web compat at stake here, really, it just doesn't seem to matter what the behavior is so having Firefox change seems easier than having IE, Blink and Safari change. In what sense is there no implementor interest? The API is already implemented, is anyone planning to remove it or is there just no one interested in trying to actually reach interoperability?
There is no implementer interest in reaching interop. Everyone's implementation (well, at least Gecko and WebKit/Blink) is scary and complicated; sites do tons of browser-sniffing; the entire execCommand() API is too rigid and so most real-world editors reimplement their own APIs in JavaScript; so no one wants to devote the resources to make changes and deal with the compat fallout. If any implementers actually wanted to make the changes necessary to be even vaguely compatible on some modest subset of real-world cases, changing this one way or the other would be a drop in the bucket, so I don't see any value in speccing a behavior that's clearly less sensible just to match the majority. Everyone's editor will need to be mostly or entirely rewritten to get to interop, similar to the HTML parser, and probably lots more iterations of the spec will be needed too. Thus, in general, I specced the most sensible behavior that looked compatible with at least one UA, and followed the majority only if no behavior seemed particularly better. If you want to take over editing the spec, feel free to change it to say whatever you want. :)
That's a pretty depressing state of affairs, but thanks for sharing :) I don't volunteer to edit the spec, and am resolving this as WORKSFORME lacking any evidence that this matters to interop. Someone™ will have to have some sense of ownership for this to make any progress, but for now it's not me.
(LATER seems like a better fit)
FWIW I don't think that the IE/WebKit behavior here makes sense at all. Therefore, at the lack of evidence for why Gecko needs to follow this behavior, I don't think I'd accept a patch to change what Gecko does here.