The substantive content of this page is from around 1997. Although various amendments have been made in the intervening years, to correct any known inaccuracies that developed, I have to admit that I have not fully reviewed the situation with the later crops of browsers.
INPUT TYPE=IMAGE is another of those situations where text-mode readers will be disadvantaged, if the author had not given them due consideration. (More details of text browser behaviour in other situations can be found in some associated documents.) Unlike the IMG tag, this one did not officially have an ALT attribute in HTML versions prior to HTML4.0, even though some text browsers already supported this "non-existent" attribute.
The HTML2.0 spec for SUBMIT TYPE=IMAGE only considered the situation where NAME=nnn had been specified (and no VALUE attribute), but there was no definite specification of what a text-mode browser should do.
As far as the display is concerned, of course a browser with images loaded will display the images; when images are not loaded, several graphical browsers merely displayed their missing-image icon and nothing more - but Netscape 3.01 (to take an example) displayed the missing-image icon and the "name" attribute, if present.
I was disappointed to find that in Mozilla (1.1, confirmed in 1.6), if image loading was turned off, the input type=image controls (e.g in the tests near the foot of this page) disappeared entirely, making the form completely unusable. It appears that this behaviour was reported in Nov.2001, but, despite the bug report stating that it could make forms unusable, the only response had been to describe the behaviour as intentional. Fortunately, this was resolved later (2003 approx).
Mozilla's behaviour when image loading was unsuccessful (server unresponsive etc.) rather than disabled, was to display the alt text if available, otherwise to display any value text provided.
In Mozilla, although the text was displayed without any kind of adornment to indicate its function as a "form submit control", it was able to be used (by a user resourceful enough to try it) for submitting the form. In which case, what was submitted by earlier versions was the name=value pair, without any name.x or name.y co-ordinates. In other words, the same behaviour that the Lynx developers had been trying to promote, years ago, in their versions 2.4-2.6. However, later versions submitted both the name=value pair, and the name.x and name.y tokens, which were set to null values in this situation.
Netscape 4 (Win 4.79 was tried) displayed the name attribute if present, but not the value nor the alt if there was no name. It did show an image placeholder in every case, though, and this was able to be used for submitting the form. Hovering over one which has a name attribute causes a copy of the name attribute to be displayed on a pop-up. Netscape 4 does not support the title attribute.
IE5.5 displayed the alt attribute if it was present, but neither the value nor the name attribute if there was no alt. It did show an image placeholder in every case, though, and this was able to be used for submitting the form. It also supported the title attribute by means of a pop-up.
In Opera (Win 6.04 was tried) with images turned off, the browser displayed the alt attribute if present; if not then it displayed the word Image
as a placeholder. In all cases the rendered result was usable for submitting the form. It also supported the title attribute by means of a pop-up.
If you're in a hurry you might want to skip to the conclusions.
Lynx (all non-antique versions, 2.4 onwards I guess), by contrast, displays the VALUE attribute, if one is present, otherwise it displays [IMAGE]-Submit. In versions 2.7 onwards it can also use an ALT attribute, if present. Note that according to the descriptive text of the various HTML specifications, INPUT TYPE=IMAGE doesn't use a VALUE attribute; however, in the way that the DTDs for the INPUT element are written, a VALUE attribute is actually permissible on any kind of INPUT element, whether or not needed according to the description. A DTD for HTML4.0 or later is needed in order to validate an ALT attribute on the INPUT tag.
emacs-w3 (I tried 3.0.62) displayed [Form-Image], irrespective of any name or value attributes, but it used the ALT attribute that I had put into one of the tests, displaying it in the square brackets instead of "Form-Image".
Now, as far as the submitted query is concerned, some known combinations are tabulated below: c,d represent decimal values of x, y co-ordinates in pixels, nnn and vvv are character strings, & is the standard forms-submission separator and (although not shown) form contents are sent encoded in the way that is specified by the standard.
WinMosaic (versions 2.1 and 3.0 were tried), when the NAME attribute was omitted, bizarrely used the NAME that had been specified on the earlier TYPE=IMAGE item, if there was one, and used it to compose a normal nnn.x=c&nnn.y=d response; but where there had been no preceding NAME attribute, it sent an empty query-string instead(!)
In Lynx versions 2.4 onwards, Foteos Macrides was trying to establish the principle that text browsers, when given both NAME and VALUE attributes, could send nnn=vvv instead of nnn.x=0&nnn.y=0, thus identifying themselves to a forms script as text mode browsers. However, this initiative was abandoned at Lynx 2.7, and he reverted to sending a regular nnn.x=0&nnn.y=0 irrespective of the presence of a VALUE attribute. Forms scripts (if a VALUE attribute is used) should be prepared to handle either kind of response, obviously.
Form submission by INPUT TYPE=IMAGEwith various combinations of NAME and VALUE |
||||
|---|---|---|---|---|
| Browser | Neither | NAME=nnn [*] | VALUE=vvv | Both |
| Netscape 2.0, 3.01, 4.5 etc. |
x=c&y=d | nnn.x=c&nnn.y=d | unaffected by vvv |
|
| Opera 2.12 |
x=c&y=d | nnn.x=c&nnn.y=d | unaffected by vvv |
|
| (Several other graphical browsers e.g MS IE, Alis Tango, gave the same results as above). | ||||
| WinMosaic2.1, 3.0 | See text! | nnn.x=c&nnn.y=d | unaffected by vvv |
|
| Lynx2.4 to 2.6 | (none) | nnn.x=0&nnn.y=0 | (none) | nnn=vvv |
| Lynx 2.7 | (none) | nnn.x=0&nnn.y=0 | unaffected by vvv |
|
| emacs-w3 (earlier report received) |
.x=0&.y=0 | nnn.x=0&nnn.y=0 | unaffected by vvv |
|
| emacs-w3 3.0.62 |
image.x=0&image.y=0 | nnn.x=0&nnn.y=0 | unaffected by vvv |
|
The column marked [*] is the situation as envisaged in the HTML2.0 standard
Pragmatically, the best chance of getting the "decorative submit button" to fall back to a readable text in most text-browsing situations seems to be to provide the same desired text on NAME, VALUE and ALT attributes! The evaluation script should also be designed so that it does not absolutely rely on the presence of name.x and name.y co-ordinates (omitted in certain conditions from Mozilla submissions), nor of the name=value pair (supplied by Mozilla, but omitted by most browsers, although arguably called-for by the HTML/4.01 specification).
But, even when these precautions had been taken, there were situations where a particular browser/version either didn't display anything, or displayed in such a way that users might not realise they could use it for form submission.
Consequently, I think the best advice has been pretty-much what it has always been: keep the input type=image for its original, imagemap-like, purpose - offering some alternative method of access for those who cannot use images - and use the straightforward input type=submit control for normal submission. Consider other techniques, such as CSS styling, to propose any desired decoration for the normal input type=submit control. But keep in mind that users mostly already know what such a "submit button" normally looks like and what it does, and it's good user-interface design to go along with that, no matter that it might not appeal to the author's own visual taste.
Here are the tests, so you can try them out yourself on the browser(s) that you use:
Status: this is a fairly historical document, only minor changes since 1997. Style-sheet fitted Feb 1999. Noticed in Apr 2000 that the NCSA reporting script is no longer available, so provided my own, plus some other cosmetic changes.
Update, noted Jan'98: ALT is an (optional) attribute of the INPUT tag in the HTML4.0 recommendation, with TITLE also available.
Original materials © Copyright 1994 - 2006 by A.J.Flavell