From tms@ansa.co.ukTue Mar 26 14:47:41 1996 Date: Mon, 25 Mar 96 19:21:01 GMT From: Toby Speight To: Alan Flavell Subject: Forms and text-browsers; some results -----BEGIN PGP SIGNED MESSAGE----- Here's what I get when I tried accessing . This is raw output; please feel free to cut it up as you wish, or summarise it in any way (though I ask you to keep my name with any use you make of it, as you usually do). BTW, the relevant versions are: WWW: 2.3.30 URL: 1.6 Emacs: FSF GNU emacs 19.30.1 on HP-UX - ----begin include Test of some Submit features This document demonstrates that it is possible to have several "submit" buttons on the same form, and to detect which one was used. Early browsers did not support this, but nowadays many do. Try it with yours. Radio Buttons for you to play with: [ ]one, [X]two, [ ]three. Use any submit button below to get the NCSA forms-test server to report your choice: Two submit buttons with name=foo, different values: bar hey Buttons with a different name, and, for variety, numerical values: 1 and 2 Oh, you need a "name", not only a "value". Here's one to try (when I use this one, the server does not tell me I pressed the shazam button, OK?): shazam Well, for completeness let's have a name without a value: Submit this form INPUT TYPE=IMAGE An input with type=image has a similar effect to a submit button: according to the text of the HTML2.0 spec, this requires a NAME attribute but does not take a VALUE attribute (however, the formal DTD neither mandates the NAME nor prohibits the VALUE attribute, and we will see later that the presence of a VALUE attribute may be useful). imageinput The response from a graphical browser is to encode the x and y co-ordinates of the click together with the "name" attribute, which in this example is "foot", sending them as foot.x and foot.y as you should be able to demonstrate. The spec does not actually say what is supposed to happen when image loading is turned off, but on the browsers that I tried it on, clicking on the missing-image area produced the same sort of effect (except of course that you may not have the full image area available for clicking, and you won't be able to see the image in order to know what to click on). The HTML2.0 spec does not actually lay down what a character-mode browser is supposed to do with an INPUT TYPE=IMAGE. In some respects this construct behaves like an IMG, having a SRC= and an optional ALIGN= attribute just like it, but it does not have an ALT= attribute, and the spec does not go into any detail about what should happen. Since Lynx plays some fancy tricks, we need three further combinations to try. Graphical browsers such as Netscape disregard the presence of a VALUE attribute, but Lynx takes a different action when it's present - for further discussion you might want to refer to my review of Lynx ALT texts etc.. imageinput has neither NAME nor VALUE, imageinput has VALUE="trek" but no NAME, imageinput has NAME="star" and VALUE="trek" In the HTML3 draft (now expired), a button is also allowed to have an image background. However, I haven't seen a browser that actually does anything with the image background (although the button otherwise works just fine): test3 Here's another frequently asked question: people want to have several submit buttons showing text strings of different lengths, but they want the buttons lined up all the same width. You can try packing out the strings with extra spaces, but it won't work reliably, I assure you that I've tried it. Another suggestion was to enclose them in TT or other monospaced markup - sorry, that doesn't seem to work reliably either. You can make them up as equal sized images and use those as submit buttons instead - they still won't line up for users who have image loading off, but ç'est la vie, and see above for the implications when used from Lynx. The HTML3.0 draft specified a "size" attribute, but did the browser makers actually implement it? Shall we see? short a very long one indeed So, you may ask, how to make buttons line up sensibly if we can't make them the same length? Well, here's one simple but effective method: Please order your favourite drink: [O] Aquavit [O] Beer [O] Champagne etc. (Your form script then has to make its selection on the basis of the "name" returned, not on the "value", since the values are all the same). Pre-filling text into input fields Somebody asked how to insert the caller's address as the default value into an input field, leaving the user the chance to amend it. Here's two methods, using server side includes. Since this is a Server Side Include, it will have been processed by the time that you see it, so I'll have to explain how it's done. All that's involved is to code at the point where you want the information, where "foo" is the name of the SSI variable as indicated below. By the way, this input file gets rejected by all the HTML validators, which is fair enough since an SGML comment isn't really valid right in the midst of an HTML construction. However, the Server Side Include feature of the NCSA httpd seems to honour it just fine, and so a validator that references the URL (and gets the document after it's been processed for SSI) is quite happy with it. First using REMOTE_ADDR in "TEXTAREA": Multiline text area Secondly using REMOTE_HOST in "INPUT TYPE=TEXT": plato.ansa.co.uk____ Special meanings for "Submit", "Clear", etc. ? Contrary to some misleading assertions I have read on usenet, there is no special meaning given by HTML to the "names" (or "values") "Submit", "Clear", etc. on an INPUT TYPE=SUBMIT button. They are just normal names (or values) that are sent to the server in the normal way, and the server will process them just as it processes any other kind of INPUT TYPE=SUBMIT. If you want to re-initialise a form, then you must provide an INPUT TYPE=RESET, which is a button having a purely local effect and not sending anything to the server. Like the TYPE=SUBMIT, the HTML3.0 draft permitted the TYPE=RESET to have an image specified via an SRC= attribute, but again I do not know a browser that implements this. Shall we try that on your browser? Reset fields There is no way to replicate the effect of TYPE=RESET by using TYPE=IMAGE: sure, you can have the server respond to a TYPE=IMAGE submission by sending a fresh copy of the form, but that's not the same thing, quite apart from the unnecessary network and server overhead, and delay. - ------------------------------------------------------------------------ Please feel free to examine the HTML source of this document: anything that isn't obvious from the source, I've tried to explain in the text - except for the NCSA forms test server, which is explained in a (rather elderly) Forms tutorial at NCSA. Anything I seem to have missed??? - ------------------------------------------------------------------------ ajf - ----end include Here are the results, in order - ----begin results You submitted the following name/value pairs: o wireless = two o foo = bar o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o foo = hey o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o submit = 1 o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o submit = 2 o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o sesame = o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o callertext = 192.5.254.64 o caller = plato.ansa.co.uk o foot.x = 0 o foot.y = 0 You submitted the following name/value pairs: o wireless = two o callertext = 192.5.254.64 o caller = plato.ansa.co.uk o .x = 0 o .y = 0 You submitted the following name/value pairs: o wireless = two o callertext = 192.5.254.64 o caller = plato.ansa.co.uk o .x = 0 o .y = 0 You submitted the following name/value pairs: o wireless = two o callertext = 192.5.254.64 o caller = plato.ansa.co.uk o star.x = 0 o star.y = 0 You submitted the following name/value pairs: o wireless = two o html3 = test3 o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o length = short o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o length = a very long one indeed o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o aquavit = [O] o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o beer = [O] o callertext = 192.5.254.64 o caller = plato.ansa.co.uk You submitted the following name/value pairs: o wireless = two o champagne = [O] o callertext = 192.5.254.64 o caller = plato.ansa.co.uk - ----end results Here's a list of the status line messages I get in the minibuffer as I navigate with TAB: - ----begin messages Form entry (name=wireless, type=RADIO) [3 times] Form entry (name=foo, type=SUBMIT) [2 times] Form entry (name=submit, type=SUBMIT) [2 times] Form entry (name=nil, type=SUBMIT) Form entry (name=sesame, type=SUBMIT) Form entry (name=foot, type=IMAGE) http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/lynx-alt-demo.html Form entry (name=nil, type=IMAGE) [2 times] Form entry (name=star, type=IMAGE) Form entry (name=html3, type=SUBMIT) Form entry (name=length, type=SUBMIT) [2 times] Form entry (name=aquavit, type=SUBMIT) Form entry (name=beer, type=SUBMIT) Form entry (name=champagne, type=SUBMIT) Form entry (name=callertext, type=TEXTAREA) Form entry (name=caller, type=TEXT) Form entry (name=nil, type=RESET) http://www.ncsa.uiuc.edu/.../Mosaic/Docs/fill-out-forms/overview.html mailto:flavell@v2.ph.gla.ac.uk - ----end messages [# times] notes were done automatically by emacs' message logging facility, so you can believe them. The multiline text area contains "192.5.254.64" (no newlines or anything). Note that this is the address of my proxy, not the host I'm running the browser on. I send a user name and address; it might be worth mentioning this as a good use of this construction for pre-initialising entry fields - actually, I wish more people would *use* this information (as a default), to save tyipng errers and so on. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMVbx5udsuUurvcRtAQHANAL/Zzo9TR/ZbvYl5pNVmeI6IxfHNMwwdRtL hv5hGTzRteKK1AjGQIMpEB5quJeAlDVOH51F5O2CX05e36h1PT57IWoCUvVyPTbW U2aPbY4k6vL5AD09KggcnVdzeI4UH3YC =b1uT -----END PGP SIGNATURE-----