lynx-dev behavior in forms

[asgilman]

>     * Subject: lynx-dev input fields that submit, and proposed option
>       names (was ...non-sticky...)
>     * From: Klaus Weide <address@hidden>
>   
>> What follows is educated hunches.
>>[ ... ]
>> I have also spoken up on the WAI User Agent list complaining about
>> automatically submitting on ENTER for forms that lack a SUBMIT element.
>> This is a trap for folks who are used to closing a text entry with ENTER.
>> Generally speaking, forms without explicit SUBMIT are treacherous in
>> eyes-free mode where it is harder to know the full extent of the form and
>> what is being submitted.  Better to be pedantic, so far as I can tell.
>
>I don't know what you mean with pedantic here - if you think of
>leaving such forms as completely unsubmittable just because some
>versions of HTML specs don't mention this behavior, that is
>unacceptable (even as a reasonable user option, IMO).
>
>The only text input fields submitted by lynx on ENTER are those that
>are *the only input field in that form*.  There is no other way to
>submit (like a "submit button").  Presumably authors use this kind of
>form to intentionally make it "easy to submit" using just the
>keyboard, because once the single field is filled out the user is
>supposed to be "done".
>
>Maybe you were thinking about some other browser's misbehavior
>instead?

Well, yes; in the WAI context I am talking about behavior that is dysfunctional
even if it is not present in any current browser.  My concern was that 
some browsers might emulate the behavior of a WinDoze dialog box where the 
logical equivalent of a SUBMIT element sits there with focus and if you 
accidentally hit ENTER at any time the transaction is committed.

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.

>
>> For what it's worth, here are my nominees for a more explanatory flag
>> name in lynx.cfg:
>>
>> One setting is OPEN_ENTRY_FIELDS:AUTO
>>
>> Its opposite is OPEN_ENTRY_FIELDS:MANUAL
>
>Yet another inconsistent term for the same thing: entry field
>vs. input field...  It turns out both are used in the UG (even combined
>as "Text entry (INPUT) fields"), but "entry field" isn't used anywhere
>in lynx.cfg.

In fact, since in HTML jargon the term INPUT is taken, and includes utterly 
static hidden values, it could be better to use 'entry' for those things 
that actually accept data from the user.

But I would be happy if the flag were termed OPEN_INPUT_FIELDS:xxx.

>
>> Don't create the hybrid.  If MANUAL, keep it that way for all fields.
>> It's hard enough to follow the modal changes as it is.
>>
>> The flag for the other one could be
>>
>>               FORMS_WITHOUT_SUBMIT_ELEMENT:SUBMIT_ON_ENTER
>>
>>               FORMS_WITHOUT_SUBMIT_ELEMENT:INSERT_ELEMENT
>
>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>.

>Anyway, there has to be *some* way to submit such forms, if not with
>ENTER then by some other mechanism.  I only come up with either YA key
>command or ENTER+confirmation as realistic choices, if the current
>behavior should need changing.

The repair idea is debatable.

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.

Thanks for the response.

Al

Al


>
>
>  Klaus
>
>     _________________________________________________________________
>   
>     * References:
>          + [12]Re: lynx-dev patch that allows text inputs to be
>            non-sticky
>               o From: address@hidden
>       
>     * Prev by Date: [13]lynx-dev Problem !
>     * Next by Date: [14]Re: lynx-dev bug in comments process
>     * Prev by thread: [15]Re: lynx-dev patch that allows text inputs to
>       be non-sticky
>     * Next by thread: [16]Re: lynx-dev patch that allows text inputs to
>       be non-sticky
>     * Index(es):
>          + [17]Date
>          + [18]Thread
>     _________________________________________________________________
>   
>   [19]Lynx mailing list archives
>   
>   [20][FLORA HOME] [21][LYNX Home]