[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Link numbering and keypad mode
From: |
David Combs |
Subject: |
Re: lynx-dev Link numbering and keypad mode |
Date: |
Wed, 17 Feb 1999 22:16:12 -0800 |
On Wed, Feb 17, 1999 at 12:52:05PM -0500, Jacob Poon wrote:
> On Wed, 17 Feb 1999, David Combs wrote:
>
> > On Tue, Feb 16, 1999 at 06:26:16PM -0500, Jacob Poon wrote:
> > > On Tue, 16 Feb 1999, Laura Eaves wrote:
> > > <big snip>
> > > I think it will be bettter to add an option to number form fields and
> > > links independently. For example, when using goto command, '123l' chooses
> > > link 123, and '123f' goes to form field 123.
> > >
> >
> > I suppose we should go all the way with this, to
> > keep from confusing the poor user.
> >
> > I mean, if these things are that different, then
> > lets have TWO SEQUENCES too:
> >
> > Links go from 1 to n.
> > Form fields go (SEPARATELY, INDEPENDENTLY) from 1 to n.
> >
> > I mean, if these two things are so different that we
> > want the user to really KNOW and BE CONSTANTLY AWARE
> > of this really IMPORTANT difference, we simply MUST do
> > this, to keep him from mentally ever mapping the two
> > into ONE concept. We MUST protect him from that error!
> >
> > Even better, have links go from 1 to n, and form fields
> > go from A to Z and then a to z -- surely no form will
> > have more than 52 fill-ins. (Well, we could add AA-ZZ
> > and aa-zz, AAA-ZZZ, aaa-zzz, and so on.)
> > At least it would keep the concepts separate in his
> > mind, thus making LYNX a far easier product for him to use!
>
> The only problem for that approach is, if links use numbers and form field
> use alphabet during serialization, what happens if I only want form fields
> to be numbered? And, if such scheme is hardcoded, what if I want both
> form fields and links to be serialized dependently (which Lynx currently
> supports)? Most importantly, if some time in future, there are demands
> for serializing other non-recursive tags (eg: images, image maps,
> scripts), then Lynx will need other types of 'numbering', which are not
> very consistent.
>
> > Further, two "L" pages, one for "true" links, and one
> > for form fields. I mean, having them both mixed together
> > on one page would lead to the erroneous idea that they
> > had some concepts in common -- we sure cannot do that!
>
> Isn't that your proposal for different serialization schemes try to solve?
>
My "proposal" was a joke, or an attempt to be one.
I guess my remark at the bottom about "on, I guess it
isn't April 1" wasn't very clear, or visible.
I was going to also propose numbering the fields
backwards, from n to 1.
I really like it the way it is now.
sorry for being so obtuse.
Cheers!
- Re: lynx-dev Link numbering and keypad mode, (continued)
Re: lynx-dev Link numbering and keypad mode, Bela Lubkin, 1999/02/16
Re: lynx-dev Link numbering and keypad mode, Laura Eaves, 1999/02/16
Re: lynx-dev Link numbering and keypad mode, Laura Eaves, 1999/02/17
Re: lynx-dev Link numbering and keypad mode, Lloyd G. Rasmussen, 1999/02/18