On Jul 23, 2012, at 4:41 PM, Ian Hickson <i...@hixie.ch> wrote: > > On Thu, 26 Jan 2012, Kornel LesiÅ~Dski wrote: >> >> But even if single-mixed-login-field autocomplete was desired, then >> perhaps a mixed type would work too: >> >> <input type="username email"> >> >> How about merging autocompletetype with autocomplete then? >> >> It looks sensible to me: >> >> <input autocomplete=off> <input autocomplete=email> > > Yeah, using autocomplete="" in this way makes a lot of sense I think.
For some of these fields, autocomplete="" as a hint to autocompletion seems sufficient. However, I think some may logically be a distinct input type as well. Some of the information represented in the proposal below is also redundant with existing type values (so it needs to be specified either twice or in a conflicting way). > > > Studying the forms in the listing cited above, it seems that fields fall > into these categories: > > Separate forms all found in the same <form>, e.g. for pages that contain > multiple products each with their own set of fields, only one product of > which is shown at a time. At a high level, the use agent should treat each > of these as a separate <form> for autofill purposes. > > Each of these can have information for different people or facets of > people: > - shipping information > - billing information > - generic user information (e.g. when it's not a shipping order form) > > Each of these sections can then have subinformation: > - name (and its subfields, such as "honorific-prefix", "nickname", etc) > - "organisation" name, the user's "organisation-title" > - physical address (and its subfields, such as "city", "state", etc) > - contact information category, e.g. "home", "work", "cell", "fax" > - each of which has subinformation such as "email", "tel" (and their > subfields, such as "country-code") There's already <input type> values of "tel" and "email", so specifying them again seems redundant. I'm assuming here a distinction between type="" and autocomplete="" -- anything that would change the appearance or behavior of the control, the syntax accepted, or the input affordances given to the user, should be a type=""; and autocomplete="" should affect autocomplete choices only. If autocomplete were to affect aspects beyond autocomplete, > - credit card details (and subfields such as "name", "exp" etc) > - personal information (such as "bday", "url", "photo") > > So we could define the autocomplete="" field's value as follows: > > "on", "off", or: > [section] [subsection] [generic-field | [contact-type] contact-field] > > ...where > > section = high-level section name; author-defined string starting > with the prefix "section-" > subsection = "shipping" or "billing" > generic-field = one of: name, honorific-prefix, given-name, > additional-name, family-name, honorific-suffix, > nickname, organisation-title, organisation, > street-address, address-line1, address-line2, > address-line3,locality, region, country, > postal-code, These all seem fine as text inputs. > cc-name, cc-given-name, > cc-additional-name, cc-family-name, cc-number, > cc-exp, cc-exp-month, cc-exp-year, cc-csc, I think cc-number is worthy of a distinctive type value. Credit card numbers have a distinctive syntax. At the very least, they are numeric and should trigger a numeric keyboard on touch devices and restriction to digits. But they cannot be <input type=number> because it would be wrong to format and localize the number (with comma or dot separators for instance), and a spinner button is an obviously inappropriate treatment. A similar consideration applies to cc-csc. These should either be assigned distinctive types, or else we need to introduce a new input type for a string of digits that is not to be formatted as a number or treated as a spinner button (<input type=digits> or <input type=numeric>). I think it is essential to do that before widely deploying these autocomplete values, or else browsers will start using the autocomplete value to drive behavior of the control itself, which defeats the purpose of having a separate autocomplete attribute. cc-exp subtypes could be distinguished by input type for cases where they are not selects. Or alternately, it would be nice if there was a way to use <input type=month> in browsers that have support for it, and the traditional two selects or two text fields. > language, bday, bday-day, bday-month, > bday-year, It's unfortunate that we don't have distinct input types for just a day, just a month, or just a year. > sex, url, photo <input type=url> exists, doesn't seem necessary to also have an autocomplete value. Also, should this not be a contact field? > contact-type = "home", "work", "cell", or "fax" > contact-field = one of: email, tel, tel-country-code, tel-national, > tel-area-code, tel-local, tel-local-prefix, > tel-local-suffix, tel-extension, impp I would suggest dropping the contact field values "email" and "tel" and instead infer them from type. So instead of <input type=tel autocomplete="work tel"> you would just say <input type=tel autocomplete=work> (and would not be able to say <input type=text autocomplete="work tel">, which would be an inferior user experience when tel is given special behavior, or <input type=email autocomplete="work tel">, which would be inconsistent). > > ...with some conformance rules, so that each section/subsection and > section/subsection/context-type group has: > > - either up to one "name" or up to one of each of "honorific-prefix", > "given-name", "additional-name", "family-name", "honorific-suffix" > > - up to one "organisation-title" > - up to one "organisation" > > - either one "street-address", or one "address-line1" > - up to one "address-line2", but only if there is an "address-line1" > - up to one "address-line3", but only if there is an "address-line2" > > - up to one of each of "locality", "region", "country", "postal-code" > > - either up to one "cc-name" or up to one of each of "cc-given-name", > "cc-additional-name", "cc-family-name" > > - up to one "cc-number" > > - either up to one "cc-exp" or up to one each of "cc-exp-month" and > "cc-exp-year" > > - up to one "cc-csc" > > - up to one "language" > > - either up to one "bday" or up to one each of "bday-day", "bday-month", > and "bday-year" > > - up to one "sex" > - up to one "url" > - up to one "photo" > > - up to one "email" > > - either up to one "tel" or up to one each of "tel-country-code" and > "tel-national" > > - if there is no "tel" and no "tel-national", up to one each of: > "tel-area-code" and "tel-local" > > - if there is no "tel", no "tel-national", and no "tel-local": up to one > each of "tel-local-prefix" and "tel-local-suffix" > > - up to one "tel-extension" > > - up to one "impp" > > > The UA conformance criteria would be pretty minimal: for each input > control with an autocomplete value that matches the above long forms, try > to determine a value that matches the description of that value (the spec > would have prose and a table describing what the values mean), and > optionally offer to set the control to that value. The values must pass > all the form control validation stuff, so e.g. if a control has > maxlength=1 and autocomplete="shipping additional-name" then the only > sensible value to offer is the middle initial of the person to which the > user is intending to ship the product. > > The documentation in the spec would recommend particular input types for > each field, and discourage the use of the decomposed forms, but there > would not be any conformance criteria there. > > Are there any common fields missing from the list above? Any categories > other than "billing" and "shipping" that should be listed? Anything other > than "work", "home", and "fax"? Should it be "work-fax" and "home-fax"? > Should we instead have the fax-* fields to parallel the "tel-*" fields, so > you can say you have a cell fax and so you can't say you have a fax e-mail > or fax Jabber? Does it make sense to have home and cell e-mail accounts > separately specifiable? Should we disallow addresses and contact details > without the "shipping"/"billing" labels? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
