W3C home > Mailing lists > Public > www-html@w3.org > May 1998

RE: HTML enhancement concept...

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>
Message-ID: <000e01bd827b$cac33160$15852399@walter>
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.


> -----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" 
> |     <input type="image" scr="/images/no.gif"     name="options" 
> |     <input type="image" scr="/images/maybe.gif"  name="options" 
> | 
> | 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
> 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
> 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"   
> |     <input type="image" scr="/images/no.gif"     name="opt-no"    
> |     <input type="image" scr="/images/maybe.gif"  name="opt-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

Version: PGP for Personal Privacy 5.5.3

Received on Tuesday, 19 May 1998 03:13:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:48 UTC