Re: request for new forms submission consensus

dcmartin@library.ucsf.edu (David C. Martin)
X-Delivered: at request of secret on dxcern.cern.ch
Message-id: <199310121845.AA26019@library.ucsf.edu>
From: dcmartin@library.ucsf.edu (David C. Martin)
Organization: UCSF Center for Knowledge Management
Email: dcmartin@ckm.ucsf.edu
Phone: 415/476-6111
Fax: 415/476-4653
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, ebina@ncsa.uiuc.edu,
        www-talk@nxoc01.cern.ch
In-reply-to: Your message of Tue, 12 Oct 1993 13:32:43 -0700
	<9310122032.AA20050@wintermute.ncsa.uiuc.edu> 
Subject: Re: request for new forms submission consensus 
Date: Tue, 12 Oct 1993 11:41:37 PDT
Sender: dcmartin@library.ucsf.edu

Now, Marc; don't ever think that I would expect this out of NCSA.  In fact,
I would like to offer code to augment Mosaic, specifically support for TIFF
images.  I don't think that having a scripting language is too much, but it
probably is too soon.

What you are creating is a client application that needs to be able to handle
displaying and navigating through an increasingly diverse network information
sea, and part of the functionality required is going to be local client
processing of interaction.

You should note that I didn't say "implement a fully scriptable viewer," nor
did I say that I even wanted such a beast.  What I was attempting to discuss
was the potential to have bindings to the new functionality you're implementing
and doing that binding in such a way as to leverage the ability of the
document creator.

Anyway, keep up the good work.

dcm
--------
Marc Andreessen writes:

David C. Martin writes:
> Completely agree!  But eventually I want to see local processing of
> actions from the user (e.g. indicating zipcode and getting state
> defaulted correctly :-) We need to start discussing the ability to
> download a script to accompany the document, e.g. in a stripped down
> TCL with TCL hooks into client (e.g. Mosaic) functionality for
> making the buttons, scrollbars, etc... *do* something interesting at
> the local machine.

Too much (and, in any case, too soon).  I feel like reposting my
"kitchen sink" speech -- we are not creating an actual full-featured
user interface builder (or building environment) here.  We are getting
close in *some* respects, but we aren't going to be able to offer the
range of functionality needed to deliver true GUI-building
capabilities, including flexibly and customizably reactive interfaces.
Therefore, I'd like to veto both the idea of arbitrarily tying
submission to any interface element (there are user interface problems
there, also -- it's not going to be clear to a user what's going on
and why) and the idea of forms behavior scripting.

Anticipating objections to my objection: During WWWWW this summer, I
was termed "closed minded" by at least one person for trying to draw
the line as to what we're willing to implement and support.  It's not
closed-mindedness, it's triage -- we just can't do everything.

Cheers,
Marc

> dcm
> --------
> Dave_Raggett writes:
> 
> Frans van Hoesel has pointed out the value in being able to
> use a checkbox or an icon or whatever to submit forms. In 
> a tax return there might be a load of questions that become
> irrelevant when you click the checkbox to indicate that you
> are "single". In this case the form would be submitted and
> the server would then return it with the irrelevant questions
> greyed-out:
> 
> Single? <INPUT NAME="single" TYPE=checkbox SUBMIT>
> 
> The idea here is to make SUBMIT an independent attribute
> that can be used with arbitrary field types. You could
> have multiple "submit buttons" in the same form. This way
> authors can choose whether the form contents gets checked
> after each field on a per field basis.
> 
> How about it?
> 
> -- Dave