[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Link numbering and keypad mode
From: |
Jacob Poon |
Subject: |
Re: lynx-dev Link numbering and keypad mode |
Date: |
Wed, 17 Feb 1999 12:52:05 -0500 |
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?
- 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