Re: lynx-dev non-sticky text inputs

[Klaus Weide]

On Wed, 28 Jul 1999, Heather wrote:

> 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.

Did it ever bother you before, or is this just an observation caused by the
current thread?

> 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.)

Use of the term 'live' isn't very clear.  I suggest we use 'current' for
what you seem to mean with 'live'.  I also suggest we use 'activated'
for the 'lineediting' state of text input fields, and for the 'popped-up'
state of popup fields.  In these terms,
  links and fields become 'current' in the usual way (by "moving" to
  them, if not initially 'current' when page is first displayed),
and
  currently:
    A 'current' popup field becomes 'current'+'activated' by ENTER;
    A 'current' textinput field becomes 'current'+'activated' automatically
    when it becomes 'current'.
  with Vlad's change, optionally:
    A 'current' popup field becomes 'current'+'activated' by ENTER (as before);
    A 'current' textinput field becomes 'current'+'activated' by ENTER.

Thinking of it this way, COLOR:6 for popups that are 'current' but not
'activated' is consistent with the coloring of normal links.  'activated'
is an extra state that normal links don't have (or, if you will, they have
that state only while nobody is looking, i.e. while we are viewing the
page that was loaded as a result of activation, and possibly in the time
while new page is loading but the old page is still displayed [but we
don't keep track of that]).  The 'activated' state of popups is pretty
obvious (as you also noted somewhere), and there are some reasons for using
mostly COLOR:0 for it: (a) COLOR:0 is the default, nothing else is said for
popped-up popups, so... (b) COLOR:0 is presumably most adequate for larger
chunks of text, less "hard on the eyes" than styles used to emphasize text
in some way.

> 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.)

It is consistent, if you agree to think of it in the terms above.  Both
(a) and (b) form my previous praragraph apply, IMO - re (b), it's useful
to have text that is being edited appear in the most "normal" and
comfortable style/color.

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

Showing the newly-introduced 'current' but not 'activated' textinput field
with COLOR:6 (highlight(ON) in the code) would be consistent.  Whether it
is actually a good choice may depend on taste or getting-used-to, maybe
it would actually look horrible, although I don't think so.  One thing it
would make quite clear though (as long as one can 'see' color or attribute
style at all - this should even apply with -nocolor for all but the most
limited term/curses): that the input field is not 'activated', i.e. not
ready for taking input.

> 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.

I would view this as "destabilizing"...
current-hyperlink (6) corresponds more to 'current' but not 'active' form field
than to 'current'+'active' fiorm field, in my view.

> 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.

That would go into the realm of color-styles...

> > >  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.

Yes.


   Klaus