The Web Design Group

INPUT TYPE=IMAGE for text users?

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 have an ALT text attribute (not officially, anyhow) in HTML versions prior to the HTML4.0 draft, even though some text browsers already supported this "non-existent" attribute.

The HTML2.0 spec for SUBMIT TYPE=IMAGE only considers the situation where NAME=nnn has been specified (and no VALUE attribute), but there is 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) displays the missing-image icon and the "name" attribute, if it's present.

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 actual DTD for the INPUT element is written, a VALUE attribute is actually permissible on any kind of INPUT element, whether or not needed according to the description. Syntax validators applying HTML versions before 4.0 will reject any ALT attribute on the INPUT tag, though.

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=IMAGE
with 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.0See 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.61 or 62
image.x=0&image.y=0 nnn.x=0&nnn.y=0 unaffected by vvv

The column marked [*] is the situation specified in the HTML2.0 standard

The most consistent behaviour can be seen to be the one specified in the standard (not suprisingly).
Provided due consideration is given to the fact that text-mode users only send co-ordinate values 0,0, all browsers send equivalent submission queries.

In the situation where the IMAGE is used merely as a decorative SUBMIT button,
provided the form analysis software is programmed to disregard the various formats of the x,y response, all should be well even if the NAME is omitted, but then it's not possible to determine which of several buttons was pressed. To distinguish between several SUBMIT buttons, a NAME attribute is required.

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! If you do that, then your evaluation procedure should be capable of taking account of the modified input parameter that would be sent by Lynx versions from 2.4 to 2.6 as noted above.


Here are the tests, so you can try them out yourself on the browser(s) that you use:

- no name or value attribute present.

- name=foo, no value attribute present.

- value=bar, no name attribute present.

- name=foo and value=bar attributes present.

- this one has the non-existent ALT attribute!

- the full works! name, value and alt text.


Status: this is a fairly historical document, only minor changes since 1997.

Update, noted Jan'98: ALT is an (optional) attribute of the INPUT tag in the HTML4.0 recommendation.


The contents of this article were originally published at http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/type-image.html.

Original materials © Copyright 1994 - 1998 A.J.Flavell & Glasgow University


Web Design Group