Re: request for new forms submission consensus
marca@ncsa.uiuc.edu (Marc Andreessen)
X-Delivered: at request of secret on dxcern.cern.ch
Date: Tue, 12 Oct 93 15:43:12 -0700
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-id: <9310122243.AA20464@wintermute.ncsa.uiuc.edu>
To: hoesel@chem.rug.nl (frans van hoesel)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: request for new forms submission consensus
In-reply-to: <9310121905.AA02599@Xtreme>
References: <9310121905.AA02599@Xtreme>
<9310122032.AA20050@wintermute.ncsa.uiuc.edu>
frans van hoesel writes:
> Initially Dave_raggett didn't like type=submit at all! He suggested to have
> only one submit button for each form.
> I pointed out to him that it can be very useful to have more.
> He came up with the suggestion not to add SUBMIT to type=, but put
> in a separate item.
>
> I too think that the browser should evolve slowly over time, but I
> don't see the point why we cannot use dave suggestion. It doesn't
> imply that you must actually implement it in all cases. But you
> could implement it for those cases that you use submit.
>
> why not simply change from
> type=submit
> to
> type=button submit
>
> and dave will be happy, you don't have to change a lot, and it would
> allow future extensions like <.. type=text submit>
> where the submit is done as soon as the user finished the text with a return,
> or <.. type=radio submit> (the form is submitted as soon as the user
> selects one of the radio buttons)
>
> I don't expect you to implement all those possibilities, but at least it
> opens the possibility to implement them, without loosing anything.
> I just want to keep the way to the futur open.
Under those criteria, the way to the future is open already.
Marc
> - frans
>
> > 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
>