Re: Refocusing on HTML

Paul Prescod (papresco@calum.csclub.uwaterloo.ca)
Wed, 04 Sep 1996 10:50:30 -0400


Message-Id: <1.5.4.32.19960904145030.0099b1f0@csclub.uwaterloo.ca>
Date: Wed, 04 Sep 1996 10:50:30 -0400
To: "Greg A. Smith" <gasmith@advtech.uswest.com>
From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
Subject: Re: Refocusing on HTML
Cc: Lee Daniel Crocker <lee@piclab.com>, www-html@w3.org

At 04:33 PM 9/3/96 -0600, Greg A. Smith wrote:
>But a Java component isn't an HTML FORM element.  In order to
>be used with the HTML FORM methodology, in which the selected
>OPTION row is communicated back to the application via a NAME=VALUE
>pair in the query string, the element must be integrated into the
>existing technology.  

That's a good point. I apologize for having not thought it through completely.

Still, Java offers the possibility of bypassing CGI altogether. Surely every
major database manufacturer wants this to be as easy as you want it to be.
That doesn't mean I don't think it is worth standardizing, I am just trying
to think of a way for you to get your project while you lobby browser vendors.

There should be a way to handle this issue in a more general sense. There
are many worthy, useful widgets ranging from slider bars to "datawindows"
and there should be a faster way to deploy them than to get browser support
for new HTML form elements. What if there were a <FORM type="applet">? The
browser would query the applet for its data when the form is submitted. The
communication mechanism between the browser and the applet would be defined
by the applet language vendor (i.e. in Java, it would be an overridable
method on the "applet" class).

 Paul Prescod