Auto fill for form fields

Since no one has shot me down (yet), here's a more detailed
presentation.

The idea is to let the user agent fill in commonly requested personal
information so the user only has to type it once. This would be
accomplished with a new AUTOVALUE (or USERVALUE or AUTOFILL?)
attribute for the TEXTAREA tag and the INPUT tag (valid only in
conjunction with the TYPE=text attribute). Values for the attribute
would be name tokens identifying the information requested. I suggest
the following as a start:

firstName, lastName, nickName (or userName?), mailto (or email, or
mailURL?), http (or homePage, or webURL, or httpURL?), title,
organization, address1, address2, city, state, postalCode, country,
phone (or maybe dayPhone and evePhone), fax.

This could obviously get out of hand, but I think we could reach
consenus on reasonably small set. (I arrived at this list by looking
at dozens of different forms. I discarded other ideas such as
password, department, mail signature, public key, credit card info,
favorite quote, etc.)

The user can provide the information (only if they are willing) to
the user agent, presumably in the preferences section. When the user
agent displays a form, it fills in the fields with the requested
values (just like with the VALUE tag). Multiple autovalue attributes
would be allowed within one tag in order to combine first name and
last name, etc. In this case the UA would separate the values by a
space if they aren't blank. (Alternately, it would be nice to allow
any combination of value and autovalue attributes to flexibly specify
the contents of the field. But this could lead to problems if the user
has left the information blank.)

Examples:
<INPUT TYPE=text NAME="Full Name" AUTOVALUE=firstName
AUTOVALUE=lastName>
<INPUT TYPE=text NAME="Addr Line 1" AUTOVALUE=address1>
<INPUT TYPE=text NAME="Addr Line 2" AUTOVALUE=address2>

I'm aware that the user's email address is already sent in the HTTP
header. I certainly don't think any additional personal information
should be supplied this way. The HTTP spec says, "The information
sent in the From field might conflict with the user's privacy
interests or their site's security policy, and hence it should not be
transmitted without the user being able to disable, enable, and modify
the contents of the field. ... We suggest, though do not require, that
a convenient toggle interface be provided for the user to enable or
disable the sending of From and Referer information." We can see how
well browser makers have followed that advice! The email address
should be included in the autovalue mechanism so that a CGI script
isn't required to pull it from the HTTP request header and put it in
the form. I should emphasize that having the user agent supply the
information at the client side when it renders a form, which the user
can then decide to change or not submit, provides decent security
(although JavaScript seems to have a method to submit a form without
the user's permission!).

Now that I've said all that, it may be possible to use the HTML 3.0
SCRIPT attribute of the FORM tag to do all this. However, I'm
uncertain of the security issues involved. The draft says, "Scripts
can't send messages over the network, or read or write files. The
library calls that are allowed are restricted to a very small and
well defined set." Does this actually restrict things enough that a
script can't surreptitously send this information without the user's
permission? It seems like the script's access to personal information
would have to be restricted to the context of a form only. This whole
scripting thing gets really complex. And I assume many browsers won't
support scripts. Therefore, the autovalue idea seems useful enough and
easy enough to implement that it's appropriate to the HTML spec.

Thank you for your attention.

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

Received on Thursday, 15 February 1996 00:28:45 UTC