Re: [whatwg] A mechanism to improve form autofill
On Tue, Oct 16, 2012 at 1:23 AM, Ilya Sherman isher...@chromium.org wrote: On Thu, 26 Jul 2012, Aryeh Gregor wrote: Government-issued ID numbers might be worth adding. In America, social security numbers are sometimes used for this purpose, but are treated as semi-secret, so you usually don't enter them on web forms. (My American college did use my social security number as an ID number, but not in web forms as far as I remember.) But in Israel, and I assume some other countries, there are national ID numbers that are considered public info. E.g., my Israeli id number (mispar zehut) is 332752187. It's printed on my checks and things like that, so it's no secret, and since it's guaranteed to exist and be unique, various institutions use it for login instead of or in addition to a username -- my bank, health insurance provider, etc. I haven't added this yet. I also haven't added: - payment instrument type - payment instrument start date - payment instrument issue number (for Maestro) I also haven't removed, as some people suggested, the three cc-name subfields. I'm open to making all these changes, but figured I would get some more input on them first, in particular from Ilya who did the research to come up with the original set of fields. I have seen a relatively high number of Chrome bug reports requesting better handling of (e.g. government) ID numbers. One example: [ http://code.google.com/p/chromium/issues/detail?id=64433 ]. I think it would be helpful to add these to the spec; though as subsequent posters have noted, there's a lot of potential complexity in how these should be represented. This might fall under the broader class of identity-related fields, which I think merit their own carefully thought out set of tokens. There was some work done on the beginnings of such a specification -- see https://wiki.mozilla.org/Identity-inputs -- but my current understanding is that this is an area in need of further development. The payment instrument type is almost certainly appropriate to add -- it is included on almost every website that I've encountered that includes payment card fields. It was an oversight on my part to omit it from the initial proposal. The other two payment instrument field types I haven't encountered on the Web, as far as I can recall. So, based on my data set accumulated while working on Chrome Autofill, I'm ok with leaving these out of the spec for now. However, my experience is biased toward US websites; it's possible that these fields are more prominent internationally. The three cc-name subfields are split out surprisingly often on existing websites. I was initially opposed to including these in the spec; but that data in support of them was overwhelming. Finally, I have gotten a request to include a field type for bank account numbers, though I have only seen this info actually requested on a small handful of extremely prominent (and generally trusted) websites: Amazon, PayPal, and I think Google Wallet. David Holloway reminded me that bank account numbers are also commonly requested when filling out United States tax forms. I have seen this information requested for tax returns on [ https://turbotax.intuit.com ]; and David pointed me to [ https://gate.link2gov.com/sfpropertytax/PropertySearch.aspx?TaxType=Secured ], which allows you to pay be e-check and asks for your bank account's routing and account numbers.
Re: [whatwg] A mechanism to improve form autofill
Apologies for the delay of this response -- I kept getting sidetracked by other tasks... On Thu, Aug 2, 2012 at 11:42 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 23 Jul 2012, Ian Hickson wrote: So we could define the autocomplete= field's value as follows: [...] I've now specced this, with some minor changes. Thanks! I think the spec is quite clear and appropriately detailed. My only high-level question is: Why did you choose to drop the proposed aliases like city for locality and province for region? While locality and region are probably the most technically correct terms -- they're certainly the best that I found while researching -- they're not terms that I'd expect most web developers to be familiar with. I think including the proposed aliases allows for a more natural way to express many site's forms; and I think that more natural/readable source HTML code is a Good Thing™. Otherwise, a bunch of minor typos and the like, all related to the parsing algorithm and subsequent sections: * In step 13.3, hint set should be hint tokens. * It seems like step 13.6 should precede step 13.5. * In step 14.3, hint set should be hint tokens. * In step 14.3, contact should be mode. * In step 14.4, I think either is is more natural than either be. * It seems like step 14.6 should precede step 14.5. * Step 18 is the last mention of the scope tokens data in the parsing algorithm, as well as in the subsequent commentary. What is the intended function of the scope tokens -- should they be combined with the hint set, or is there a separate notion of scope that should be invoked by the UA when parsing this attribute? * In the paragraph beginning with Suppose a user agent knows of two phone numbers, there is a typo: pefilled - prefilled. * For terms like autofill hint set, should the spec use autocomplete rather than autofill, or is there an intentional distinction being made here? 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). I'm a little wary about adding more magic here, these attributes are already pretty complicated. See the autocomplete section's algorithms and let me know if you still think we should do something along those lines. If it's something people are willing to implement, I wouldn't want to stand in the way; I agree that it has some good side-effects (like making it impossible to have certain combinations). I could also introduce some conformance requirements to make the bogus combinations non-conforming; currently I haven't made type=tel autocomplete=email non-conforming for instance. Since the autocomplete type hints are just hints, I think it's ok to leave this behavior undefined; but I also don't see any problem with making such mismatches non-conforming, other than that makes the spec even longer/more verbose. On Thu, 26 Jul 2012, Aryeh Gregor wrote: Government-issued ID numbers might be worth adding. In America, social security numbers are sometimes used for this purpose, but are treated as semi-secret, so you usually don't enter them on web forms. (My American college did use my social security number as an ID number, but not in web forms as far as I remember.) But in Israel, and I assume some other countries, there are national ID numbers that are considered public info. E.g., my Israeli id number (mispar zehut) is 332752187. It's printed on my checks and things like that, so it's no secret, and since it's guaranteed to exist and be unique, various institutions use it for login instead of or in addition to a username -- my bank, health insurance provider, etc. I haven't added this yet. I also haven't added: - payment instrument type - payment instrument start date - payment instrument issue number (for Maestro) I also haven't removed, as some people suggested, the three cc-name subfields. I'm open to making all these changes, but figured I would get some more input on them first, in particular from Ilya who did the research to come up with the original set of fields. I have seen a relatively high number of Chrome bug reports requesting better handling of (e.g. government) ID numbers. One example: [ http://code.google.com/p/chromium/issues/detail?id=64433 ]. I think it would be helpful to add these to the spec; though as subsequent posters have noted, there's a lot of potential complexity in how these should be represented. This might fall under the broader class of identity-related fields, which I think merit their own carefully thought out set of tokens. There was some work done on the beginnings of such a specification -- see https://wiki.mozilla.org/Identity-inputs -- but my current understanding is that this is an area in need of
Re: [whatwg] A mechanism to improve form autofill
On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jul 2012, Smylers wrote: Ian Hickson writes: Also, I do not understand why we have credit cards types. Is anyone willing to have his credit cards information saved locally? Sure, why not? I am too, but I can understand why people who share their computer (and user accounts) with others wouldn't want their card numbers saving. That's a UA configuration issue, presumably. (Similar to saving passwords.) In fact, Chrome already autodetects credit card numbers for autofill (presumably based on a heuristic) and has a special dialog for whether to remember them, similar to the password-remembering dialog. At chrome://chrome/settings/autofill, there are fields for both addresses and credit card numbers. This is documented here: https://support.google.com/chrome/bin/answer.py?hl=enanswer=142893p=settings_autofill IIRC, one option when it asks you to remember credit cards is don't ever remember credit card numbers -- although I'm not sure, since I think I picked it and thus haven't seen the dialog in a long time. :)
Re: [whatwg] A mechanism to improve form autofill
On Fri, Aug 3, 2012 at 5:31 AM, Aryeh Gregor a...@aryeh.name wrote: On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 26 Jul 2012, Smylers wrote: Ian Hickson writes: Also, I do not understand why we have credit cards types. Is anyone willing to have his credit cards information saved locally? Sure, why not? I am too, but I can understand why people who share their computer (and user accounts) with others wouldn't want their card numbers saving. That's a UA configuration issue, presumably. (Similar to saving passwords.) In fact, Chrome already autodetects credit card numbers for autofill (presumably based on a heuristic) and has a special dialog for whether to remember them, similar to the password-remembering dialog. At chrome://chrome/settings/autofill, there are fields for both addresses and credit card numbers. This is documented here: https://support.google.com/chrome/bin/answer.py?hl=enanswer=142893p=settings_autofill IIRC, one option when it asks you to remember credit cards is don't ever remember credit card numbers -- although I'm not sure, since I think I picked it and thus haven't seen the dialog in a long time. :) In practice the credit card portion of Chrome Autofill is not very useful since most (hand-wavy) sites that contain credit card fields in forms use autocomplete=off, which Chrome respects. There is a third-party Chrome extension which removes autocomplete=off to solve this issue. James
Re: [whatwg] A mechanism to improve form autofill
On Mon, 23 Jul 2012, Ian Hickson wrote: So we could define the autocomplete= field's value as follows: [...] I've now specced this, with some minor changes. On Wed, 25 Jul 2012, David Holloway wrote: A contact address might be helpful for sites that are non-commercial in nature. Airlines and hotels often ask for contact information such as here: https://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/autofill/heuristics/input/10_register_hotels.com.html?revision=89396view=markup Or, optionally: subsection = up to one of: shipping or billing Where omitting the subsection covers the general case. I went with making shipping/billing optional. Anything other than work, home, and fax? Should it be work-fax and home-fax? mobile, pager? Added those. On Wed, 25 Jul 2012, Maciej Stachowiak wrote: 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). I've added a section that details the difference between type=, inputmode=, and autocomplete=. Let me know if that doesn't answer your questions on this front. 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. As far as I can tell, this is just input type=text inputmode=numeric. 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. Without script, that's hard. With script it's possible today. 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. Why? (What's wrong with type=number, select, and type=number respectively?) input type=url exists, doesn't seem necessary to also have an autocomplete value. As with the others, type=url just means the data type is URL, it doesn't mean the value is my home page. Let me know if you still disagree after having read the section I added to the spec and I'll reconsider. :-) Also, should this not be a contact field? Do people have different home pages based on whether they're at home or at work or on their cellphone? 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. Please let me know if you still support this after reading the aforementioned section in the spec. (In particular, the spec talks explicitly about the tel case.) 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). I'm a little wary about adding more magic here, these attributes are already pretty complicated. See the autocomplete section's algorithms and let me know if you still think we should do something along those lines. If it's something people are willing to implement, I wouldn't want to stand in the way; I agree that it has some good side-effects (like making it impossible to have certain combinations). I could also introduce some conformance requirements to make the bogus combinations non-conforming; currently I haven't made type=tel autocomplete=email non-conforming for instance. On Wed, 25 Jul 2012, Anne van Kesteren wrote: This
Re: [whatwg] A mechanism to improve form autofill
On Tue, Jul 24, 2012 at 2:41 AM, Ian Hickson i...@hixie.ch wrote:
Are there any common fields missing from the list above?
Government-issued ID numbers might be worth adding. In America,
social security numbers are sometimes used for this purpose, but are
treated as semi-secret, so you usually don't enter them on web forms.
(My American college did use my social security number as an ID
number, but not in web forms as far as I remember.) But in Israel,
and I assume some other countries, there are national ID numbers that
are considered public info. E.g., my Israeli id number (mispar zehut)
is 332752187. It's printed on my checks and things like that, so it's
no secret, and since it's guaranteed to exist and be unique, various
institutions use it for login instead of or in addition to a username
-- my bank, health insurance provider, etc.
So it might be useful to remember. I don't know if it's a common
enough need to make it into a first pass, though, since I guess most
countries don't have it. If it is, probably you'd want to have
subtypes for every country's id number, maybe using a country code
suffix.
I would also like to point out that this feature seems to overlap with
not only type= (as has been pointed out), but inputmode= as well,
and for that matter pattern=. I think it would be quite unfortunate
if authors found themselves writing things like
input inputmode=numeric pattern=\d{16} autocompletetype=cc-num
because that's logically pretty redundant. But maybe it's the only
way to preserve our sanity, because it allows authors to figure out
what combination of features they need for their inputs instead of us
trying to figure out in advance what the possibilities are.
Re: [whatwg] A mechanism to improve form autofill
On Jul 25, 2012, at 11:21 PM, Aryeh Gregor a...@aryeh.name wrote:
I would also like to point out that this feature seems to overlap with
not only type= (as has been pointed out), but inputmode= as well,
and for that matter pattern=. I think it would be quite unfortunate
if authors found themselves writing things like
input inputmode=numeric pattern=\d{16} autocompletetype=cc-num
because that's logically pretty redundant. But maybe it's the only
way to preserve our sanity, because it allows authors to figure out
what combination of features they need for their inputs instead of us
trying to figure out in advance what the possibilities are.
The specific combo of features you list is highly foreseeable. You may be right
that there will be harder to predict scenarios.
the flip side is that a multidimensional matrix of features affecting form
elements is more complicated to understand, more likely to be implemented in a
buggy way, and more likely to be used wrong by authors.
Regards,
Maciej
Re: [whatwg] A mechanism to improve form autofill
Aryeh Gregor writes: ... in Israel, and I assume some other countries, there are national ID numbers that are considered public info. In the UK library user ID 'numbers' are useful on multiple sites. As well as the local library's own website, it grants access to many reference sites that the library subscribes to, such as those of 'The OED' and 'Encyclopædia Britannica'. Similarly there are other organizations that one can be a member of whose ID numbers need to be provided to multiple websites. For example with some loyalty cards or frequent flyer programmes points can be collected from multiple retailers. It would be really useful if the auto-fill mechanism could cope with such ID numbers: they are often long strings which few people know from memory. So I'm wondering if there could be a 'membership' or 'ID number' field-type, followed by an identifier which organization this is, such as: membership-uk-library membership-israel-id membership-flypoints or: idnum-uk-library idnum-israel idnum-flypoints This would be different from the other autocomplete field types Hixie has proposed, because the organization suffix is open-ended, rather than from a fixed set. I think that's inevitable: the HTML standard can hardly spec every organization that somebody could be a member of. It would be up to each organization that issues membership numbers to decree the suffix that's used for it. Other websites that have forms requiring membership numbers for that organization presumably already have a relationship with it, so can easily ask them which suffix to use; there's no particular need for a central list where one can look up an arbitrary organization's suffix. Clashes are possible, of course, but I suspect in practice if organizations chose their own name (including a geographic part if the organization is specific to a particular country or region) this wouldn't be a big problem. 'Number' above is in scare quotes, since some of these types of ID numbers contain letters as well. OpenID URLs could be viewed as one example of cross-site membership, so could possibly be covered by a system such as this. But since OpenID is an open standard which anybody can use, and isn't tied into a particular organization, an autocomplete type specifically for OpenID URLs may be worthwhile. Cheers Smylers -- http://twitter.com/Smylers2
Re: [whatwg] A mechanism to improve form autofill
Maciej Stachowiak writes:
On Jul 25, 2012, at 11:21 PM, Aryeh Gregor a...@aryeh.name wrote:
I would also like to point out that this feature seems to overlap
with not only type= (as has been pointed out), but inputmode= as
well, and for that matter pattern=. I think it would be quite
unfortunate if authors found themselves writing things like
input inputmode=numeric pattern=\d{16} autocompletetype=cc-num
because that's logically pretty redundant.
The specific combo of features you list is highly foreseeable.
Perhaps specifying certain autocomplete types could set defaults for
pattern and inputmode? So for this example autocomplete=cc-num would, if
pattern isn't specified, imply pattern=\d{16}, and equivalently for
inputmode?
You may be right that there will be harder to predict scenarios.
By having the highly foreseeable cases merely be defaults for pattern
and inputmode, it allows anybody doing something less predictable to
still set those attributes explicitly.
The complicated cases would be possible, but wouldn't force redundancy
on the common cases.
Cheers
Smylers
--
http://twitter.com/Smylers2
Re: [whatwg] A mechanism to improve form autofill
On Thu, Jul 26, 2012 at 11:52 AM, Smylers smyl...@stripey.com wrote:
Perhaps specifying certain autocomplete types could set defaults for
pattern and inputmode? So for this example autocomplete=cc-num would, if
pattern isn't specified, imply pattern=\d{16}, and equivalently for
inputmode?
That would be surprising, because autocomplete is just a hint, while
pattern doesn't allow form submission if it's not met. Also, I
couldn't swear to you that all credit card numbers are actually 16
digits, or that they will forever be 16 digits, so I'm hesitant to
make that connection canonical.
Re: [whatwg] A mechanism to improve form autofill
Aryeh Gregor writes:
On Thu, Jul 26, 2012 at 11:52 AM, Smylers smyl...@stripey.com wrote:
Perhaps specifying certain autocomplete types could set defaults for
pattern and inputmode? So for this example autocomplete=cc-num
would, if pattern isn't specified, imply pattern=\d{16}, and
equivalently for inputmode?
That would be surprising, because autocomplete is just a hint,
That's a matter of definition. If you squint autocomplete could be seen
as the 'purpose of this field' attribute (which just happens to be
called autocomplete because we already have an attribute of that name to
build on).
pattern doesn't allow form submission if it's not met.
Possibly only surprising to people who bother to think about it in those
terms. I suspect many web developers would simply find it convenient.
Also, I couldn't swear to you that all credit card numbers are
actually 16 digits,
True. But whatever the actual pattern is, it isn't useful to the owner
of a debit card with an 18-digit number if the pattern varies between
sites and some only allow 16 digits to be submitted.
I'd rather trust Hixie to find out what the rules are and bake them into
the spec than for every separate webmaster to try to get this right,
because some inevitably won't, especially if there are rules which
apparently work for many common cases but actually exclude a minority.
or that they will forever be 16 digits, so I'm hesitant to
make that connection canonical.
If the format for credit card numbers changes significantly enough to
break patterns that have been working for years, we're in trouble
wherever those patterns have been specified.
Cheers
Smylers
--
http://twitter.com/Smylers2
Re: [whatwg] A mechanism to improve form autofill
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,
Re: [whatwg] A mechanism to improve form autofill
On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak m...@apple.com wrote: 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. This is also true for the inputmode attribute. In particular its Telephone, E-mail, and URL states. If we add this, we should also add guidance on how type/autocomplete/inputmode work together. -- http://annevankesteren.nl/
Re: [whatwg] A mechanism to improve form autofill
On Jul 25, 2012, at 12:36 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak m...@apple.com wrote: 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. This is also true for the inputmode attribute. In particular its Telephone, E-mail, and URL states. If we add this, we should also add guidance on how type/autocomplete/inputmode work together. Yeah, it seems like having both input type=tel and input inputmode=tel is redundant. If they had different behavior, that would be awful. If they have the same behavior, then why do we need both in the platform? Similarly, I'm confused about the need to have both input type=number and input inputmode=numeric. They are not exactly the same, but it is mysterious that one is a type and the other is the inputmode. Also, neither is appropriate for pure digit strings such as credit card numbers of CVVs, where the thousands separator and negative indicator should never be added, either explicitly by the user or as part of formatting by the UA. Regards, Maciej
