Re: Auto fill for form fields

I was writing a huge response when Netscape 2.0 crashed on me. In
retrospect I'll defer to Mozilla's editorial wisdom. Here is a much
shortened version....

Jim -- your proposal, as is, doesn't solve enough to be sufficiently
worth the changes it would entail. Its key difficulty is the dependance
on a global naming system. If the naming system is small the scheme will
lack functionality. If it is large it will be too hard to manage.

> Adam's "intelligent agent" matching of aliases to field names is
> pretty slick,

Thanks -- but not so. The problem is vastly reduce when there is
more context available. I believe the context provided by the user's
choices and the URL, or site, can remove the requirement for a global
name table.

I allowed the user to pick and chose what was stored and what was
filled in. The intelligence was in the user. The mechanism was merely
to match an identifier to a value and an improvement would be to do so
within the context of a URL or site. I think of this as similar to
the Netscape cookie idea.

> One of the databases is an ancient TeleMagic thing with cryptic
> 3-letter field names. I doubt any agent, no matter how clever, will
> know that NM1 is first name, NM2 is last name, and US7 is e-mail.

A human can and can tell the user agent. Sure, the form doesn't
get filled in automatically the first time but that is a good thing
not bad. A user is submiting information and should not do so with
blind trust on a form that hasn't been read and understood.

> but there's no reason the browser/agent couldn't do a
> fallback match on the NAME attribute if the AUTOVALUE attribute isn't
> present. The automatic fill in process would then at least partially
> work on most existing forms.
>
If the user agent ought work without AUTOVALUE, and I think it
should, then when do we need AUTOVALUE? I assume for those few
cases where the name might clash. Is that worth it?

> PASSWORD(??),

(??) Agreed. It would be, IMHO, a bad idea.

> At this point, "autovalue" starts to lose it's meaning, so perhaps
> the already defined ID attribute (or even CLASS) could be used, as
> long as this doesn't warp its intended usage.
>

You were referring to ID & CLASS in this, right?

	http://www.w3.org/hypertext/WWW/MarkUp/html3/input.html

From my reading of this spec it would warp ID which is intended for
use with style sheets. One could use the ID as a unique identifier
but not define the content of what ID was set to.

With ID how would you cope with multiple instances of the same
data item on multiple forms within and HTML docuement? ID must be
document wide unique.

I believe this would potentially also clash with other uses of CLASS.

>
> This is so easy to add to HTML that I see no reason not to.
>
Some reasons. IMHO, why not to :

1) The many people hours required to modify existing forms.
2) The many people hours involved in learning the new standard.
3) Writing HTML forms will be harder and more time consuming w/
looking up the correct field names.
4) It isn't backwards compatible - so nothing will work on all the
exist forms untiul they are modified.
5) The limited functional return.

Erik Aronesty's posting made it clear that there are far too many
things to do with HTML to consider adding attributes without a
wide applicability. We are approaching only one task of automatic
processing of HTML forms.

Now, off to read the proposal Daniel just mentioned....

Adam
--
+1-203-730-5437 | http://www.micrognosis.com/~ajack/index.html
ajack@corp.micrognosis.com -> ajack@netcom.com ->  ajack@?.???

Received on Monday, 19 February 1996 09:35:51 UTC