Re: lynx-dev Link numbering and keypad mode

[Jacob Poon]

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?