Re: [whatwg] A mechanism to improve form autofill

2012-10-18 Thread Ilya Sherman 
On Tue, Oct 16, 2012 at 1:23 AM, Ilya Sherman  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

2012-10-16 Thread Ilya Sherman 
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  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  you would just
> > say  (and would not be able to say
> > , which would be an inferior
> > user experience when tel is given special behavior, or  > 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 further developme

Re: [whatwg] A mechanism to improve form autofill

2012-08-03 Thread James Hawkins 
On Fri, Aug 3, 2012 at 5:31 AM, Aryeh Gregor  wrote:

> On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson  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
> , there are fields for both
> addresses and credit card numbers.  This is documented here:
> <
> https://support.google.com/chrome/bin/answer.py?hl=en&answer=142893&p=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

2012-08-03 Thread Aryeh Gregor 
On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson  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
, there are fields for both
addresses and credit card numbers.  This is documented here:

 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

2012-08-02 Thread Ian Hickson 
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=89396&view=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  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 ( or  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 .


> 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  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, , and type=number 
respectively?)


>  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  you would just 
> say  (and would not be able to say 
> , which would be an inferior 
> user experience when tel is given special behavior, or  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 is also true for the inputmode attribute. In particular its 
> Telephone, E-mail, and URL states.

I've de-empha

Re: [whatwg] A mechanism to improve form autofill

2012-07-26 Thread Smylers 
Ian Hickson writes:

> On Thu, 15 Dec 2011, Ilya Sherman wrote:
> 
> > 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.

> > Is any website not using autocomplete=off as soon as credit cards
> > are involved?
> 
> Those that do that are incredibly annoying.

A site using autocomplete=off enables a distinction to be made between
sensitive and non-sensitive fields, for users who want such a
distinction.

For users who wish everything to be saved, a browser (or an extension)
could be configured to ignore autocomplete=off when it's present.

Not using autocomplete=off makes it impossible for the first group of
users to make their desired distinction. Using it still enables the
second group to have their desired behaviour, given an appropriately
configured browser.

The relevant part of the spec currently says that for autocomplete=off:

  the user agent should not remember the control's value, and should not
  offer past values to the user.

Could we turn those "should not"s into "may choose not to" or similar,
to indicate that there's nothing wrong with browsers offering users such
a feature? Or possibly to "must not ... unless the user has specifically
configured the user agent to enable remembering sensitive data"?

If there is to be an autocomplete type for payment card numbers then I
think that the restrictions on saving autocomplete=off values should
also apply to them. I suspect sites currently using autocomplete=off for
card numbers would be unwilling to switch to autocomplete=cc-number if
it meant all users card numbers would suddenly start being saved.

There may be users who are happy to have their long card number (which
they can't remember) saved but not their CSC (which is easier to
remember) or 3D Secure password. Maybe a browser could ask the first
time a user submits a card payment what they want saving.

Thinking specifically about payment card input, but more generally than
just autocomplete, these features would be useful as a user:

* When entering a new number, if I type or paste in spaces or hyphens
  they are stripped from the number submitted to the site.

* If the number doesn't pass the Luhn check digit algorithm, treat the
  field as invalid and refuse to submit the form until I've fixed it.

* Save the card type (Amex, Visa credit, Visa debit, etc) along with the
  other details. Not all sites ask for this, but a significant number do
  have a select box for it, and it's tedious to have to select each
  time.
  
  Unfortunately this is a 2-dimensional quantity. Some sites group all
  Visa cards together; others list Visa credit and Visa debit on
  separate lines; and some others don't care about the brand but want to
  distinguish between credit and debit cards, sometimes because the
  price charged to the customer differs between those two.

* For my browser to have multiple sets of card details stored, which I
  can pick from.

* For the browser only to fill in stored card details of types that are
  accepted. For example:

  » I prefer to pay with my credit card, but some sites only accept
debit cards. So I'd like to have my credit card details stored and
used on most sites, but the debit card details also stored and used
on those that don't accept credit cards.

  » Some people prefer, say, Amex, but have a Mastercard they use on
sites that don't accept Amex.

  » The 2012 Olympics box office only accepts Visa. It's pointless the
browser filling in the details of any other brand of card.

* If a card's CSC is stored for the browser to fill this in when making
  a repeat transaction on a site that stores my card number but prompts
  for the CSC each time. I think the East Coast trains site in the UK
  does that, and Amazon if shipping to a new address.

  For this to work for a user who has multiple card numbers stored in
  her browser, the site needs to indicate not just that the text box is
  for a CSC, but which card it is for. This is typically displayed to
  the user as a card number with most of the digits replaced by Xs, and
  sometimes with the card type as well; a way of specifying that in
  mark-up would enable a browser to pick the appropriate card.

* To fill in 3D Secure password characters, for the payment card being
  used.

  Unlike the other card payment fields, a stored 3D Secure password
  (Verified by Visa and similar) only needs to be sent back to one site,
  that of the card issuer, not to every site taking payment. However, if
  multiple cards are stored by the browser (say a debit and credit card
  from the same issuer) then the correct password needs to be picked --
  the one that goes with the card number submitted a page or two back --
  which requires the browser knowing this is a 3D Secure p

Re: [whatwg] A mechanism to improve form autofill

2012-07-26 Thread Smylers 
Aryeh Gregor writes:

> On Thu, Jul 26, 2012 at 11:52 AM, Smylers  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

2012-07-26 Thread Aryeh Gregor 
On Thu, Jul 26, 2012 at 11:52 AM, Smylers  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

2012-07-26 Thread Smylers 
Maciej Stachowiak writes:

> On Jul 25, 2012, at 11:21 PM, Aryeh Gregor  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
> > 
> >  
> > 
> > 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

2012-07-26 Thread Smylers 
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

2012-07-26 Thread Maciej Stachowiak 

On Jul 25, 2012, at 11:21 PM, Aryeh Gregor  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
> 
>  
> 
> 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

2012-07-25 Thread Aryeh Gregor 
On Tue, Jul 24, 2012 at 2:41 AM, Ian Hickson  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

  

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

2012-07-25 Thread Maciej Stachowiak 

On Jul 25, 2012, at 12:36 PM, Anne van Kesteren  wrote:

> On Wed, Jul 25, 2012 at 8:54 PM, 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.
> 
> 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  and  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  and 
. 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

Re: [whatwg] A mechanism to improve form autofill

2012-07-25 Thread Anne van Kesteren 
On Wed, Jul 25, 2012 at 8:54 PM, 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.

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

2012-07-25 Thread Maciej Stachowiak 

On Jul 23, 2012, at 4:41 PM, Ian Hickson  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:
>> 
>> 
>> 
>> How about merging autocompletetype with autocomplete then?
>> 
>> It looks sensible to me:
>> 
>>  
> 
> 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 , 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  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  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  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 ( or ). 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  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

 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

[whatwg] A mechanism to improve form autofill

2012-07-23 Thread Ian Hickson 

[This was a long thread. I have omitted comments that repeated earlier 
points and those that made good points that were addressed in detail by 
earlier answers by other people on the thread. If you had a specific 
comment that did not receive a reply from me but for which you would like 
specific reply, please don't hesitate to mail the list again asking for 
clarification.]

On Thu, 15 Dec 2011, Ilya Sherman wrote:
>
> Current autofill products rely on contextual clues to determine the type 
> of data that should be filled into form elements. Examples of these 
> contextual clues include the name of the input element, the text 
> surrounding it, and placeholder text.
> 
> We have discussed the shortcomings of these ad hoc approaches with 
> developers of several autofill products, and all have been interested in 
> a solution that would let website authors classify their form fields 
> themselves. While current methods of field classification work in 
> general, for many cases they are unreliable or ambiguous due to the many 
> variations and conventions used by web developers when creating their 
> forms:
> 
>   + Ambiguity: Fields named "name" can mean a variety of things, 
> including given name, surname, full name, username, or others. Similar 
> confusion can occur among other fields, such as email address and street 
> address.
> 
>   + Internationalization: Recognizing field names and context clues for 
> all the world’s languages is impractical, time-intensive, and 
> error-prone (as good context clues in one language may mean something 
> else in another language)
> 
>   + Unrelated Naming: Due to backend requirements (such as a framework 
> that a developer is working within), developers may be constrained in 
> what they can name their fields. As such, the name of a field may be 
> unrelated from the data it contains.
> 
> We believe that website authors have strong incentive to facilitate 
> autofill on their forms to help convert users in purchase and 
> registration flows. Additionally, this assists users by streamlining 
> their experience.

This does seem to be a valid problem.


On Thu, 26 Jan 2012, Ilya Sherman wrote:
> On Thu, 26 Jan 2012, John Tamplin wrote:
> >
> > One question -- how does this fit with, say, a  element for 
> > country that shows localized country names?  Can it be "autocompleted" 
> > as well?  If so, does it match on the localized names, the value 
> > (which might be an ISO 2 or 3-digit code, or something unique to the 
> > app), or what?
> 
> I would expect that this varies across autofill agents.  For Chrome, we 
> handle this case pretty well by leveraging the ICU library [ 
> http://site.icu-project.org/ ].

s are an interesting problem, because they limit the valid inputs. 
So do features like maxlength="", pattern="", etc. I suppose the solution 
is to allow the user agent to have multiple possible autofill values for 
each autofill field, or to just allow the user agent to make suggestions 
based on any information it may have... Actually we pretty much have to do 
that anyway. There's not really any UA-testable conformance criteria for 
this feature, it's just providing information for the UA to make more 
intelligent editors possible.


On Sun, 22 Jan 2012, Mounir Lamouri wrote:
> 
> Looking at the list of types you are proposing, I was wondering if we 
> couldn't solve this another way. We could create two new input types: 
> 'contact' (or person, or anything better) and 'address'. 'address' could 
> even be part of 'contact' given that is a contact information. There is 
> currently some work being done to access contact information.
> 
> Currently, the way we handle names and addresses is probably suboptimal 
> and websites have to re-invent a lot of things. A simple field that 
> would ask the user to give those information might be way better for 
> both authors and users. For example, on a mobile phone, I would be able 
> to pick up one of my contact address to send him a gift instead of 
> typing it.

I have no objection to us introducing new input types, but that seems 
orthogonal to the issue of introducing a way to label a field as being a 
certain piece of data.

That is, "address" is a type; "shipping address" is a field. A fax 
number, mobile number, home number, work number: they're all "tel", but 
they're each different fields.

Anyway, if we want to experiment with higher-level types like "address" 
then I recommend interested vendors implement such ideas in their dev 
versions as e.g. type="x-address". I think that's somewhat orthogonal to 
what we have in the realm of autofill -- existing pages and database 
schemas are based on certain fields, which is presumably what we should 
expose. But similarly, we shouldn't preclude this being added in the 
future. This suggests that maybe we should have a field name "address" 
that encompasses all the various address-related fields into one. Might be 
best to leave that out until we have such