- From: Walter Torres <walter@tscinternet.com>
- Date: Mon, 18 May 1998 12:48:08 -0400 (EDT)
- To: "WC3 Mailing List (E-mail)" <www-html@w3.org>
- Cc: "Carl Morris" <msftrncs@htcnet.com>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I placed my original post sometime ago. I really never got much of a response to it. I guess the group never really felt it was much of a topic that needed discussion. I just completed a project that had this very issue as one of our sticking points. So, I am replying to Carl (I don't have any record of my originally replying, sorry Carl) here hoping that after some time this might initiate some responses. Walter > -----Original Message----- > From: Carl Morris > Sent: Friday, September 27, 1996 2:59 PM > To: Walter Torres > Subject: Re: HTML enhancement concept... > > | I have "discovered" something very interesting in my wonderings through HTML > | and various permeation's of forms. > | > | (Yes, this is basic stuff!) > | > | You can have multiple submit buttons, like so... > | > | <input type="submit" name="options" value="Yes"> > | <input type="submit" name="options" value="No"> > | <input type="submit" name="options" value="Maybe"> > | > | And if you hit the second button, the browser will return... > | options=No > | > | This makes it real nice to have a semi-smart CGI to deal with the same data > | slightly different depending on which button the user selected. > > Yes, it does. I am implementing a CGI-game with this right now ... > about 9 buttons all in the same form... > > > | This makes it real nice to have an semi-smart cgi to deal with the same data > | slightly different depending on which button the user selected. > | > | You can also use an image for a submit button. > > Nope... not true ... as you point out, clicking on the image submits > it, but is not really a submission button... Well, isn't having an Image fire off the submit command of a Web form, in practice the same thing as the Image being a Submit Button? Or are we splitting hairs here? Or maybe I should have said: "you can use an Image in place of a Submit Button." > > | So, based upon the above example, and the fact you can have images as submit > | buttons, I can theorize the following... > | > | <input type="image" scr="/images/yes.gif" name="options" value="yes"> > | <input type="image" scr="/images/no.gif" name="options" value="no"> > | <input type="image" scr="/images/maybe.gif" name="options" value="maybe"> > | > | And if you hit the second button (just like the previous), the browser will return... > | options=No > | > | But this is not the case. The browser returns... > | options.x=25&options.y=10 > | > | This is the coordinates where the mouse clicked on the graphic. What I should have said here... These are the coordinates where the mouse hit *a* graphic. But we don't know Which graphic was hit and I think that this is important. > | > | This information is fine if I have an image map as a multiple submit buttons, or a single image supporting a single submit button. > | > | But what if I want multiple images to represent multiple submit buttons? > > Then what you want is a way to replace the submit button itself with > an image ... not a TYPE=IMAGE... and as yet there is no way to use > replacement graphics for true SUBMIT buttons... A CSS1 entity could > replace the graphic possibly, but in HTML it would be harder to define > a standard that worked well... I really don't think that is what I was saying. I am just looking a way to enhance the current syntax to include additional information without breaking existing programs. - -- This ends Carl's remarks, below is just the remainder of my original post. -- > | > | I could simply modify my submit code as such... > | > | <input type="image" scr="/images/yes.gif" name="opt-yes" value="yes"> > | <input type="image" scr="/images/no.gif" name="opt-no" value="no"> > | <input type="image" scr="/images/maybe.gif" name="opt-maybe" value="maybe"> > | > | With this change in the NAME, I would get the following results... > | opt-no.x=25&opt-no.y=10 > | > | With this output, I would have to modify my CGI to parse the return string and > | toss out anything after period. > | > | Somewhat a minor task, but annoying on the whole. > | > | The reason for this letter is not to simply rant, or to teach you about submit > | buttons and images, but to propose a simple solution. > | > | Since the normal Submit button returns the NAME and VALUE in a readable format, and the > | image button returns coordinates in a nice co-ordinate parsing fashion, I would like to > | propose that the image (used as a) submit button, return both data types in the > | following manner. > | > | options=no&options.x=25&options.y=10s This solution tells us which image was hit *and* where it was hit. A very nice and neat little package. > | > | This gives us both sides of the coin so developers can use which ever method they > | need to use for whatever purpose they need it for. > | > | I hope this will spark some discussion on this subject. > | > | Walter Torres And again, I really hope to hear some discussion on this topic. Walter Torres -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQA/AwUBNWBkgv+OfRYguQRIEQJHAACbBxH8HW1lyoFn3nKEqQqHaS69LZwAn18t 1Q+hmig+6LpFStkyeqre2pcf =CI0Z -----END PGP SIGNATURE-----
Received on Tuesday, 19 May 1998 03:13:02 UTC