Re: lynx-dev Link numbering and keypad mode

[David Combs]

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!