Re: lynx-dev non-sticky text inputs

[Heather]

> > unhighlighted, so on page where textinputs come in chain, user will lose
> > control on what the current link is (this looks very confusing, believe me).
> 
> Ok, I think I understand now (please correct if I'm wrong):
> You want the field to have the same appearence as if one was line-editing,
> even if one has not yet 'entered' the field.  This is to make clear which
> is the 'current' link-or-field.
> 
> I didn't think of this.  I imagine though that having a 'not yet entered'
> field appear the same as a 'field that is being edited' can also be
> confusing in a different way.  Is there a way to visually distinguish
> those last two cases?  (Maybe by the position of the text cursor?  Maybe
> by statusline?)

In my present use of color lynx (2.8.1rel2), form input fields "feel" much 
like hotlinks, in terms of moving to them.

In terms of color they're kinda crazy.

Picklist fields that aren't open seem to be the same color as live hotlinks 
(in my case br.yellow on brown, color 6), but when they are open, they're a 
different color (br.white on black, color 2 for the selection, lt.grey on
blue, color 0 for deselected others). (why statusline color for a pick
field, I have no idea.)

Textfields which I'm not at are lit (br.yellow on blue, color 1), while those
which I am at, active for input, turn yet another color (lt.grey on blue,
color 0).  (why it should color like plaintext when it just became live, I 
have no idea.)

If I understand the new feature I could be on the field, but not yet active
for input.  Oh no!  Not another color!

Given these, anything that stabilizes what all form fields look like would
be an improvement.

I'd kind of rather that the live/active "you are here" color remain that 
assigned to the current-hyperlink (6), and the inactive color be that of 
unselected hyperlinks (1)  while if these fields are being skipped, normal
color (0 or per modifiers) would be right.  Pickfields can be "entered" --
Text fields that could be entered, should have similar color characteristics
to the pickfields in similar state.

If it isn't too much extra, perhaps lynx.cfg color entries could be created 
for form fields so that I could color them uniquely from hyperlinks entirely.
But, that's a different subject.

> >  Please expain (or  <some variable> will be equivalent in semantics to
> > textarea_activated)?
> 
> No, <some variable> would just be the global setting that determines whether
> auto-inputfield-entering (or however it is called) is ON or OFF.

To hold the user's preference, not the current field's state.

> But I realize now that, with that simple approach (if it worked), a current
> input field that is not yet entered would look indistinguishable from non-
> current ones - which you want to avoid.  So it can't be done this simply.

The desire I described above would involve lynx knowing when it was on a live
field.  Can you not steal the logic presently used for pickfields to determine
when it is popped up or closed, and apply it to text fields now?

> Except if we can use a different way to distinguish looks - see below.
> sent expeditiously...
>    Klaus

Come to think of it a pop-open box would make it pretty clear you had "entered"
the field.  Why, full textareas could almost look like they're really seperate
somehow.

* Heather