Re: lynx-dev behavior in forms

[Klaus Weide]

On Thu, 29 Jul 1999 address@hidden wrote:

> >     * Subject: lynx-dev input fields that submit, and proposed option
> >       names (was ...non-sticky...)
> >     * From: Klaus Weide <address@hidden>

> What I mean by pedantic in this case is that it takes two user actions to 
> a) complete the input of data into this field and b) commit the transaction
> at the FORM level.  
> 
> Your suggestion of ENTER plus a status-line confirmation query would, of
> course, satisfy this.

Well that could be done without too much effort, if it really helps some.
(Configurable option to extra-prompt (a) for all form submissions / (b) for
input-field only submissions / (c) never.)

> >I don't know what INSERT_ELEMENT is meant to imply.
> 
> The idea is similar to the transform from SELECT to RADIO button array.
> 
> It is meant to suggest that a repair could be performed in which _any_ 
> FORM lacking a SUBMIT element would be provided with a vanilla SUBMIT, 
> just inside the closing </FORM>.
> [ ... ]
> 
> The repair idea is debatable.

It is very questionable, especially in the more general case of '_any_
FORM lacking a SUBMIT element'.  I wouldn't want to be responsible for
making a form submittable when the author obviously has not cared to
do so (except perhaps by some scripting means).

There's also no good way to know the best place for an artifical "Submit"
button.  The </FORM> can happen in a completely unrelated place, for example
the end of the document or some table.

> An option to require confirmation on _all_ form submits (not just quickie
> submits of single-field forms) could benefit some users, I think.  See
> Checkpoint 10.5 in 
> <http://www.w3.org/WAI/UA/WAI-USERAGENT-19990716/>.
> 
> By the way, now is a good time for people to read and comment that draft.
> It is in a public review cycle right now.



   Klaus