Message-Id: <31288BED.2FEA@corp.micrognosis.com> Date: Mon, 19 Feb 1996 09:40:45 -0500 From: Adam Jack <email@example.com> To: "Jim Taylor (remote)" <JHTaylor@videodiscovery.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: 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 email@example.com -> firstname.lastname@example.org -> ajack@?.???