Re: lynx-dev non-sticky text inputs

[Heather Stern]

Klaus Weide wrote:
> 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?

It didn't bother me enough to whine about it, once I set all my background
colors except status-line to blue, and my hypers to brown.  That's why it's 
annoying that pickfields use status color, except I don't have to see them
very often anyway. 

Essentially it's annoying, but not harmful to *my* usage, so it's 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),

I meant by "live" the present method, where they become 'current' and 
'activated' in the same action.

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

Hmm.  Put it that way, that makes sense.  But it doesn't explain why statusline
color is used instead of hotlink for the pickfield/current selection.

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

I disagree, I like to have the thing that I am working on bright and more
vibrant than the standard text scattered around it, but haven't stressed 
very hard about it.  I don't seem to have end-user means to seperate it.

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

Did I see someone suggest bounding the field with curly braces when it was
current + activated?  That would certainly show in -nocolor.

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

ok, diagram time:
                   Not Current         Current Only     Also Activated    
PICK LIST          [desl.hotlink]       [hotlink]       status/ normal + drawn
TEXT 1-line        _desl.hotlink_          *            _normal_  
TEXTAREA           _desl.hotlink(ea.)_     *            _normal_ (1 line only)
RADIO              (desl.hotlink)       (hotlink)       changes state
buttons             desl.hotlink         hotlink        invokes form

* being currently proposed.

Um, anyways his patch would make the two starred entries possible, then we
can argue over what color they should be (though I agree with you, they
should be hotlink color while current-only).

I disagree with the direction I see Also-Activated going for textarea, it's
barely normal that they look like a group but are treated as individual lines
already.  Treating them even more individually would piss me off, every 
single day.

I disagree about form gadgets becoming normal color, I want to be able to 
(for instance) have all my form parts in cyan:black as they become active.
But your justification for the color is borne out, as "normal"
it's bearable enough, that I hadn't bothered to complain, either.

I like pickfields becoming line-drawn when they pop open;  I'm kind of hoping
I'll see that for textareas someday.  And it would be acceptable to me to see
those upon opening 1-line text fields, if they were normally closed as I 
travelled past them.

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

Yeah, I guess so.  Of course, I can't color my form gadgets seperately in
any graphical browser but Old Mosaic, so it's not like I'm gonna hold my
breath or something.

* Heather