W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: any more comments? ('204 No Content' clarification)

From: David Morris <dwm@shell.portal.com>
Date: Thu, 24 Aug 1995 00:10:45 -0700 (PDT)
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.90.950823235533.26981A-100000@jobe.shell.portal.com>

On Wed, 23 Aug 1995, Marc Hedlund wrote:

> What is a UA expected to do with form fields in this circumstance?  If a
> script is to take input and leave the form in view, it would be useful to
> clear the form fields without changing the document.  This would: (1) give
> a visual indication that something has happened; and (2) allow repeated
> entries (i.e., data entry) to the same form without reloading or <input
> type="reset">-ing.

I have a real concern about automatic resetting of fields. Such behavior
presumes that repeated input will be different rather than a small
change from the last input. In general, clicking a reset button isn't
that big a deal considering all the mouse manipulation required to
position oneself for the next input.  And then, in addition to reset,
should the form reposition itself to the beginning? Killing the user's
ability for one last confirmation could also be frustrating.

There are some applications (e.g., Lou's example of CHAT) where immediate
recycle is known to be desireable to the application implementor and
perhaps also to the user.

This is not a behavior which should be triggered as a side effect of
other useful bahaviors (like staying on the same document). When and
if it occurs it should be explicitly requested.

I would suggest a new <input> type for 'SUBMIT&RESET' then the
application implementor can offer an appropriate button and even a
choice for the user.  This would apply without respect to whether the
application also provided a confirmation page.

Dave Morris

(PS. For some applications, like chat, and for error feedback from
many others, it would be very useful to have a response which said
that the output page now arriving should REPLACE the current page.
CHAT would use this to provide a scrolling dialog window without filling
the user's history cache and data base interactive applications could 
provide a much more effective error feedback as well as applications
which might perform actions such as filling in a customer name and
address while leaving the screen about the same.)
Received on Thursday, 24 August 1995 00:14:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC