Re: lynx-dev non-sticky text inputs

[Klaus Weide]

On Wed, 28 Jul 1999, Heather Stern wrote:

> Klaus Weide wrote:
> > On Wed, 28 Jul 1999, Heather wrote:
> > > Key to get in, and key to get out, must be assigned.  Enter is an okay 
> > > choice for single lines, but terrible as exit key for textarea fields,
> > > since it's pretty common to want to do a paragraph or two in those.  I'm
> > > sure that's all been argued out on entirely different threads before.
> > 
> > Thanks for answering, I didn't realize that 'editor' is synonymous with
> > 'vi' for you. :)
> 
> Well, it isn't really. In this case it's "whatever's built into lynx" 
> analogous with Elm's +BUILTIN, but the vi description did help explain 
> the modal nature, didn't it?

Ok, please forget my 'vi' remarks. :)

To recapitulate, all you meant with modal is that there would be two
modes - a 'command mode' and an 'input mode' - right?
 
> > > > >      >  F_TEXT_SUBMIT_TYPE  ?
> > > > > 
> > > What if this weenie's form has more than one text
> > > field?
> > 
> > Then it needs a submit button or some other INPUT field that
> > acts in that capacity, or lynx cannot submit it.
> > 
> > (Which weenie?)
> 
> weenie = the web author who assumes all browsers have auto-submit features.
>
> Um, so it only works for sure if it's the modern (myopic) equivalent of 
> searchable index pages.  Okay.
> 

Real weenies use javascript to make unsubmittable forms.

I assume for one-input-only forms the behavior is pretty widespread
and quasi-standard (otherwise it probably wouldn't be used on
www.freshmeat.net), although I couldn't find it in HTML 4 when I just
looked.

> > That means two ENTERs are necessary for submitting.
> > 
> > More reason to make 'current'+'activated' look obviously different
> > from 'current', so a user won't accidentally submit because he assumes
> > the next ENTER is a first ENTER when in fact it is the second ENTER.
> 
> I think it ought to be pretty clear if a field is hotlink color instead
> of edit color, that something is going to happen when they hit ENTER.

That's my untested proposal, to give it 'hotlink color'.

So far, Vlad relies on (a) text cursor position (b) different statusline
to make the difference visible.  [ It just occurs to me, does the statusline
also apply in Novice and Intermediate user modes?   - probably it does. ]

> Um, come to think of it, now I'm confused.  A text field can also have 
> a default value.  So I would have to activate the field even though I don't 
> want to edit it, to get into a mode where I can submit.  Yes?

Sure.  Not any different from where you are after filling in some text, then
moving somewhere else, then returning, I assume.

A text input field pre-filled with "" isn't treated any different from one
prefilled with "foobar".

> How to tell if there's no colors?  That curly brace stuff that was suggested?

curly brace doesn't apply for empty and not-too-long contents.

> How about current/inactive text fields grow brackets?  People pretty much
> know brackets go around hotlinked things by now.

(a) It seems I'm not one of "people". (b) Are text fields "hotlinked" in
any usual sence of the word? (except perhaps F_TEXT_SUBMIT_TYPE)
(c) Try for yourself with -nocolor how things appear without color (at
least in your environment, which is different from other people's non-color
environment).  Maybe it isn't necessary that fields grow curly things,
it wasn't so far. 

   Klaus