And in particular, the text in the spec makes it very likely that the alt text will be cut off.  The difference from normal image behavior seems pretty unnecessary and confusing.

This bug was cloned to create bug 18258 as part of operation convergence.

The spec says:

"When an input element whose type attribute is in the Image Button state does not represent an image and the user agent does not expect this to change, the element is expected to be treated as a replaced element consisting of a button whose content is the element's alternative text. The intrinsic dimensions of the button are expected to be about one line in height and whatever width is necessary to render the text on one line."

Why would rendering it as inline text be better? Surely rendering as a button is more appropriate.

It's common for web pages to style image inputs with a width and height.  So while a button is more appropriate if the alt text is short, in practice doing that makes the alt text pretty much useless to the user.  :(

The text I quoted doesn't mention the height and width attributes; it explicitly says the text shouldn't be cut off. I don't understand the problem here.

The width and height attributes are mapped into style, so if the object is not a non-replaced inline, they affect the rendered size.  And then your options are overflowing (hence overlapping, hence unreadable) text, or text that's cut off.

Ok, I've made height/width not apply in this case. Is that sufficient?

Checked in as WHATWG revision r7614.
Check-in comment: Make width/height attributes not apply to <input type=image src=404> so that the button text doesn't get cut off in the common case.
http://html5.org/tools/web-apps-tracker?from=7613&to=7614

I'll need to think about it.  There are likely to still be issues if the text is wide enough to not fit in the viewport, unfortunately,

It's a submit button, a wide label isn't likely to be correct anyway.

That's possible, but I'm not clear on why we want these to have different behavior from <img>, exactly.....

Because they're interactive submit buttons, not inline text like <img>.

<img onclick> is an interactive button too...

Basically, the distinction seems arbitrary to me.  Which correspondingly means that implementing anything like this is very low priority, of course.

<img onclick> for a button is like <span onclick> for a link or <div onclick> for a button. Not good practice. <img onclick> is more correctly used not as a button, but as a piece of text or image that has some interaction (this is a similar distinction between a link and a button).

Understood about implementation priorities, of course.

I'm leaving the spec as-is here, since even though this isn't widely implemented as per the spec, there doesn't seem to be a compat reason _not_ to do it as per the spec, and what the spec suggests seems (slightly) better. So it's one of those things that we'll hope implementors eventually get to, even if it does take a while. (If there's a compat reason not to do this, though, please do reopen.)