lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev non-sticky text inputs


From: Heather
Subject: Re: lynx-dev non-sticky text inputs
Date: Wed, 28 Jul 1999 16:54:09 -0700 (PDT)

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

Yes.

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

To this, I have to agree, but to nitpick, said Real Weenie uses a page
creator program which generates javascript such that the forms don't work,
and either crashes or looks quite ... curious ... in at least one 
js-enabled browser variant.

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

I think it was A Particular Browser's idea of robustness at corrupt forms,
and authors took off with it because it was a comfortable way to specify
what to say instead of "this is a searchable index"

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

Vlad, don't do that - it may be true that the cursor hops around, but I never
look for it, so it being someone's only indicator is probably not a good idea.

[ Seems that it does, at least on 2.8.1rel.2 - Novice shows two lines of 
menu on bottom-most, statusline above that, total spent = 3 lines. 
Intermediate spends only one, tells me how to do things at a normal link,
but doesn't say what URL it goes to. I think in both these modes more status
messages are generated, but it's hard to say, since as soon as I learned
my way about I went immediately for showing URLs and serious messages. ]

(BTW as I switched modes, I noted, the pickbox on options form, userlevel,
starts out painted ltgrey:blue with statusline color for picked item.  Moved
one up to "Intermediate" - 2. in front of that + 3. Advanced all turned
white:blue.   I double checked the color setting for the machine I'm in, it's
one of the ones with color 0 and 4 both white - there's no ltgrey in this 
context that came from me!  How'd that happen?)

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

Oh.  Then I can hardly tell how it's going to show without screen attributes.
Even my local colorless has attributes - dull, bright, and reverse.

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

That's what I mean, that a submit-type text field would grow brackets so
it would look like a button... um, in whatever state has it being a submit
button, that is.  The other state should look as present to not confuse people.

Come to think of it, that does not sound easy to code. :(

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

Yeah, I know.  I toggle between them when showing someone the old days.
(Brings a grin. I pop open the options dialog and turn off a whole bunch
of stuff, then say, "THAT is what some of your customers are seeing.")

I don't think non-submit fields have to grow brackets, I'm just trying to
think of a way to make submit textfields more obvious, now that it's pointed
out color isn't always sufficient.  Another status line message?  Maybe.

If a text field has the following states:
        unselected
        selected but non-edit         <-- + submit if applicable?
        edit

How do we show 4 or 5 states, where we only needed two before?  Drawing
a box for 1 liners is overkill... probably bandwidth wasteful over telnet,
too.  (I just thought of, we could use dots instead of underlines for an
inactive text input, but it would still need to be repainted)  

Colors are pretty but don't exist for everyone.  Are colors currently 
implemented as apply-attributes or as repaint-the-text?  If the latter
maybe  
ENTER OUR COOL FORM
    Your Name: .......................
    Your URL: ........................             <-- not selected
                                                   = unselected color
    Why you're cool enough for our form:
        Because I use lynx____________             <-- activated
                                                   = selected color + change
I'm Cool, submit it       Not so cool, reset it

versus
    Why you're cool enough for our form:
        Because I use lynx............             <-- selected, not active
                                                   = selected color


My color=off environment offers reverse and bold.  You noted that some
folks only get one enhancement method (likely there are some who don't have
that, and have to use numbered links or something).

When I'm not in my comfy net environment, but out and about, I may be using
someone else's lynx, then may I end up colorless (or may choose colorless over
tasteless selections).  But in such cases I won't see benefit, unless they
upgrade.  (Of course, I am able to help them if they need :> )  (Yes, if
I stick around long enough I can set lynxrc entries.)

* Heather

reply via email to

[Prev in Thread] Current Thread [Next in Thread]