Re: Auto fill for form fields

   From: Adam Jack <ajack@corp.micrognosis.com>
|
|   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.
|...
|
|   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.
|...
|   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?
---

Well, the answer is implicit in the second quoted paragraph, above -
with defined names, the browser can fill in data the first time it sees
the form.  Obviously, diifferent people use different forms in different
ways.  There are a few forms I have used repeatedly, but many more that
I have used once (typically to establish an account or subscription).
A method that can only learn from experience will never be helpful for
what is, for me, the more common case of one-time use.

Note, also, that an autovalue scheme doesn't have to *only* use
pre-defined names - the browser could prompt for a value the first time
it sees a given token name and remember it - but it does depend on the
names being managed.  My own model would be that the namespace contains
a small set of globally defined names (part of the standard) and a rule
that authors defining tokens not in that standard set use a prefix on
ther token names.  Thus, my division of Motorola (MCG) could put the
prefix MOTOROLA_MCG_ at the beginning of all its names.  Authors could
also reuse existing names with well-known semantics.  Neither kind of
sharing is possible if the browser has to use the source of the document
as the disambiguator; the browser would again have to ask for the help
the first time it saw a token.

---

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

This probably does fall in the intended scope of CLASS the set of, for
instance MOTOROLA_MCG_COMMERCE_ID values is a meaningful subclass of
the text input.  I think this is arguably the best way to handle this
(see below).  It requires no change to the HTML spec and only a small
extension to the CSS1 spec.

---
|   >
|   > 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.
---

1) existing forms still work - you don't *need* to modify them; what's
the average maintenance cycle on forms, anyway?

2) negligible

3) negligible - the set of "standard" names would be tiny (and trivially
embedded in authoring tools)

4) true

5) Again, I don't think the ability to pre-fill the obvious "common"
fields on forms, the first time seen, is "limited".

Again, I agree that a tool that watches and remembers how forms are
filled in would be useful; however, a method for encoding in the form
what kind of data should be entered in a given field would make that
tool's job easier, as well as making it possible to fill in common
fields of many forms the first time they are seen.

On Friday I thought SGML entities might be the simplest way to do this.
After thinking about it some more, it might be better to use CLASS to
indicate the kind of value, coupled with a small extension to the
stylesheet mechanism to allow text insertions:

	<STYLE...>
		INPUT.user-email	{text-value "your-name@your-system"}
	</STYLE>

The author could include defaults in the STYLE element of her
document and the user could override them in her browser.

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com

Received on Monday, 19 February 1996 10:50:24 UTC