Re: Auto fill for form fields

Great comments from Adam Jack <ajack@corp.micrognosis.com> and Scott
E. Preece <preece@predator.urbana.mcd.mot.com>.

Adam's "intelligent agent" matching of aliases to field names is
pretty slick, but I have to agree with Scott that there are too many
variations for this to be reliable. For example, I have written forms
that feed into a database so I use the database field names in the
NAME attribute for a direct mapping. 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. And Adam pointed out that there
could be a clash with a field called "name" that has nothing to do
with the user's name. So I maintain that an AUTOVALUE attribute is
important, 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.

It does make sense to try to fill in other form elements such as
selections, checkboxes, etc. I was trying to keep things simple, but
it's probably better to define something that's comprehensive.
Therefore, the AUTOVALUE attribute could be allowed on INPUT types of
TEXT, PASSWORD(??), CHECKBOX, RADIO, SCRIBBLE, IMAGE, and on the
OPTION and SELECT elements (in addition to TEXTAREA). 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.

Because of the immense variety of data requested by forms, trying to
define a reasonable set of name tokens as part of HTML may be doomed
to failure. As Scott suggested, "...it would be safer to provide a
base capability in the form of a set of defined names. A user agent
would still be free to implement a learning/guessing scheme to
augment that set." I believe we can kill two birds with one
attribute: we can leave it completely open-ended for custom or
"proprietary" field identifiers, but also define a recommended set of
identifiers. Apple succeeded in a similar task by  creating an open
Apple Event mechanism but also defining (and letting the developer
community define) additional standard "suites" of events. 

It would still be nice to have HTML 3.0 include a minimal set of
predefined name tokens to cover the most commonly requested
information (such as first name, last name, and e-mail) that all but
the lamest browsers could support, but beyond that we could
informally (or maybe via RFC) define standard identifier suites such
as identification (company, address, SSN, public key)  payment
(credit card, cybercash account), personal statistics (age, race,
income), school registration, IRS forms (that would be a huge one!),
etc. An online registry for keeping track of them would be handy. 

The browser/agent interface for keeping track of all these
identifiers and their values would probably look something like the
one for mapping MIME types to helper applications. Are there already
any standards for identifying pieces of information in this manner?
EDI?

This is so easy to add to HTML that I see no reason not to. It's just
one attribute for certain form elements, plus perhaps a few predefined
tokens for the attribute. Browsers and other agents are free to
support it however they like. And I can't think of any place more
appropriate to implement the mechanism than in HTML.

________________________________________________________________
Jim Taylor <mailto:jhtaylor@videodiscovery.com>
Director of Information Technology
Videodiscovery, Inc. - Multimedia Education for Science and Math
Seattle, WA, 206-285-5400, <http://www.videodiscovery.com/vdyweb>

Received on Saturday, 17 February 1996 20:29:39 UTC