17630 2012-06-28 14:48:23 +0000 Image inputs with no image should fall back to non-replaced elements, just like normal images 2013-04-12 22:58:49 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WORKSFORME http://www.whatwg.org/specs/web-apps/current-work/#images P3 normal 2015 Q1 1 contributor ian bzbarsky ian mike contributor oldest_to_newest 69490 0 contributor 2012-06-28 14:48:23 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html Multipage: http://www.whatwg.org/C#images Complete: http://www.whatwg.org/c#images Comment: Image inputs with no image should fall back to non-replaced elements, just like normal images Posted from: 98.110.194.72 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/16.0 Firefox/16.0 69491 1 bzbarsky 2012-06-28 14:52:20 +0000 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. 70983 2 contributor 2012-07-18 17:51:58 +0000 This bug was cloned to create bug 18258 as part of operation convergence. 73083 3 ian 2012-08-30 19:08:28 +0000 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. 79169 4 bzbarsky 2012-11-30 07:56:50 +0000 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. :( 80710 5 ian 2012-12-30 05:44:24 +0000 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. 80713 6 bzbarsky 2012-12-30 06:18:05 +0000 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. 80726 7 ian 2012-12-30 19:34:17 +0000 Ok, I've made height/width not apply in this case. Is that sufficient? 80728 8 contributor 2012-12-30 19:35:22 +0000 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 80735 9 bzbarsky 2012-12-30 20:19:24 +0000 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, 80743 10 ian 2012-12-31 03:40:27 +0000 It's a submit button, a wide label isn't likely to be correct anyway. 80784 11 bzbarsky 2012-12-31 06:49:27 +0000 That's possible, but I'm not clear on why we want these to have different behavior from <img>, exactly..... 80805 12 ian 2013-01-01 03:18:21 +0000 Because they're interactive submit buttons, not inline text like <img>. 80806 13 bzbarsky 2013-01-01 04:22:35 +0000 <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. 80917 14 ian 2013-01-05 02:13:06 +0000 <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. 86098 15 ian 2013-04-12 22:58:49 +0000 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.)