[whatwg] Various autocomplete="" topics

On Wed, 5 Mar 2014, Qebui Nehebkau wrote:
> On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson <ian@hixie.ch> wrote:
> > I think the arguments you've presented so far suggest "address-levelN" 
> > for N=1..4, with 4=region and 3=locality, is probably the simplest 
> > thing to do. I was hoping there might be other people with opinions, 
> > to give us different perspectives on this, but it seems nobody else 
> > cares. :-(
> 
> Since you asked, I think the whole endeavour (of trying to tokenise an 
> address) is pointless and should be abandoned outright. :)

In principle I agree, but in practice I think we have to work with the 
reality that that is what people are doing.


> Short of my ideal of *only* offering the full address (as used on a 
> label) as an opaque string, I think it would be most reasonable to 
> consider the 'locality' field itself to be a fully-specified opaque 
> string, including whatever information is necessary to completely 
> identify the location from the region level (such as the prefecture and 
> district), rather than a single level.
>
> Failing all that, I would at least prefer for the fields to have names 
> instead of abstract numbering, because people are likely to be confused 
> about the order, no matter which end is the 'widest'. It also seems more 
> intuitive, to me, for the 'locality', as, after all, 'local', to be the 
> most specific level.

Would people not be confused by names in the same way?


On Wed, 5 Mar 2014, Qebui Nehebkau wrote:
> 
> Right, "impose", certainly not. But, perhaps, (one hopes,) "encourage"? 
> Or at least "refuse to explicitly support anything else". Does 
> autocomplete *need* to support people who are already doing it wrong? 
> But I'm probably just being too utopian; it happens.

Well if we don't support pretty much every form out there, the feature 
isn't particularly useful.


On Tue, 4 Mar 2014, Kevin Marks wrote:
> > > > > > > >
> > > > > > > >    "address-line1" |
> > > > > > > >    "address-line2" |- "street-address"
> > > > > > > >    "address-line3" |
> > > > > > > >    "address-level4"
> > > > > > > >    "address-level3"
> > > > > > > >    "address-level2" / "locality"
> > > > > > > >    "address-level1" / "region"
> > > > > > > >    "country-name"
> > > > > >
> > > > > > This could work. It has the synonym issue (having multiple fields
> > > > > > that mean the same thing is often the source of confusion).
> > > > > >
> > > > > > > > Or we could do:
> > > > > > > >
> > > > > > > >    "address-line1" |
> > > > > > > >    "address-line2" |- "street-address"
> > > > > > > >    "address-line3" |
> > > > > > > >    "subsublocality"
> > > > > > > >    "sublocality"
> > > > > > > >    "locality"
> > > > > > > >    "region"
> > > > > > > >    "country-name"
> > > > > >
> > > > > > This could work. It avoids the synonym problem.
> > > > >
> > > > > Yes, this alternative works, but in my opinion is not preferable.
> > > Because these words don't really mean anything.

Nor do numbers. I think we don't really have any chance of giving meaning 
to the names here either way.


On Tue, 4 Mar 2014, Evan Stade wrote:
> 
> "dependent-locality" and "locality" have a fairly precise meaning in the 
> UK. Also in a natural-language conversation, if you ask me what "region" 
> of the country I live in, I'd say "New England", "the Midwest", or some 
> such; certainly not the state where I reside. The descriptions for these 
> tokens are currently pretty specific, for example they say a city would 
> be a locality. But this is not true for Beijing or some other cities. To 
> fix the descriptions, we'd have to change them to something like 
> "region: the highest level administrative region below country in the 
> address" and "locality: the second-highest level administrative region 
> below country in the address", "sub-locality: the third-highest level 
> administrative region [...]".

With you so far.


> At this point, one wonders why the tokens aren't just [something]1, 
> [something]2, etc.

I don't understand how you get there. Why would you wonder this?


> > > > > > > >    "address-line1" |
> > > > > > > >    "address-line2" |- "street-address"
> > > > > > > >    "address-line3" |
> > > > > > > >    "locality"
> > > > > > > >    "subsubregion"
> > > > > > > >    "subregion"
> > > > > > > >    "region"
> > > > > > > >    "country-name"
> >
> > I don't understand why you think authors will think they need to 
> > include "subregion", but won't think they need to include 
> > "address-level3".
> 
> I think they'll assume subregion returns something for the US if it's 
> sandwiched between "region" and "locality", because county is in between 
> state and city. But in reality, subregion will return nothing.

But why does this not apply to the numeric version?


> > Having synonyms is really bad. It leads to huge amounts of confusion. 
> > This is why I'm trying to avoid having synonyms for the address-level* 
> > stuff. We should definitely not add some just to introduce a slightly 
> > better name.
> 
> My suggestion is to change the address-line1 to street-address-line1, 
> not to have synonyms. Chrome would then support address-line1 for a 
> limited period of time, but outside the spec.

There's no "outside the spec". The spec tries to describe reality. If you 
implement something, then that's the reality, and that's what the spec 
would say, and therefore we'd have a synonym.


> If you are avidly anti-synonym for the address-level* stuff, and don't 
> want to change "region" and "locality", then I guess the next best 
> naming scheme in my mind would be "region", "locality", "locality2", 
> "locality3". But we also need to update the descriptions as mentioned 
> above.

I don't understand why "locality2" is better than "sublocality", nor why 
it's better to add things above locality than between locality and region.

The numbering seems really prone to mistakes (I mean, I've been making 
mistakes with it this entire thread unintentionally, for example).


> > > Why is that better than 1=region, 2=locality, except to a US-centric 
> > > viewpoint? This would lead to a weird situation where (a) you 
> > > couldn't expand past 4 levels without changing the meaning of 
> > > previous levels and (b) a country such as the US would have 
> > > address-level4 and address-level3 but no address-level2 or 
> > > address-level1.
> >
> > Well, at least as far as (a) goes, we have no way to know where 
> > governments are going to introduce new levels. Who's to say that the 
> > US won't introduce something between states and towns? This problem 
> > exists whatever we do. Maybe the US and the EU will merge and there'll 
> > be a new field between "country-name" and "region". Who knows.
> 
> One can dream...
> 
> You're right that changing political circumstances might put us in an 
> awkward situation no matter what we do. But it seems to me the most 
> likely scenario is that a government would add more administrative 
> levels at the most granular level.

Why? It seems just as likely that we'll add levels between "country" and 
"region". For instance, the example above. Or, in a few years, when there 
are parts of countries in space, maybe there'll be a planetoid name 
between the country and the region. Or maybe that will go on the other 
side of the country.

I think trying to guess how things will be extended is a fool's errand.

If we use numbers, we paint ourselves into a corner with extensions 
anywhere but at the deepest level.


Fundamentally, studying all the alternatives we've considered so far, they 
all suck.

 - some have weird names like "subsubregion".
 - some use numbers
 - some have synonyms
 - some leave gaps in addresses for some locales where it's not 
   obvious where the gap should be
 - some are non-trivial to extend later

I think I'm going to just go with more or less what you first proposed:

   "address-line1" |
   "address-line2" |- "street-address"
   "address-line3" |
   "address-level4"
   "address-level3"
   "address-level2" / "locality"
   "address-level1" / "region"
   "country-name"

That is, make "locality" and "region" synonyms for two new fields, add two 
more, and say in the spec that different locales have different numbers of 
levels and that as many should be included as are appropriate, starting 
with level1 as the widest administrative division.

I've filed a bug on this topic; if I can get agreement from other vendors, 
then I'll go ahead and spec this:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235



On Wed, 5 Mar 2014, Edward O'Connor wrote:
> 
> The techniques browsers use for autofilling auth information would 
> benefit enormously from some additional autocomplete="" values. The wiki 
> page Ilya mentioned captures the use cases pretty well. I think these 
> are the critical ones that capture the most common cases:
> 
> # Passwords
> 
> On "change your password" forms, which <input type=password> is your
> current password? Which is the new password? Browsers want to avoid
> filling the old password into the new or confirm password fields.
> Additionally, distinguishing such fields would help tools that generate
> passwords. These are useful on both sign-up and change password forms.
> 
> <input type=password>                      - your current password
> <input type=password autocomplete=new>     - a new password
> <input type=password autocomplete=confirm> - the new password, again
> 
> Next to the other autocomplete values, "new" and "confirm" don't look
> descriptive enough. "new-password" and "confirm-password", maybe?
> "<input type=password autocomplete=new-password>" feels redundant and
> verbose to me.

Is there any reason to have two fields here, why not just "new" both 
times?

Also, should we have an "old" field for the old password, or is the lack 
of an autofill field sufficient?

I've filed a bug to track this:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236

It needs multiple vendors on board to make progress.


> # Usernames
> 
> Lots of websites use email addresses as usernames. Tools should be able
> to distinguish email-used-as-username fields from other email fields.
> This can also help on "forgot password"/"forgot username" forms.
> 
> <inpyt type=text autocomplete=username>  - your username on this site
> <input type=email>                       - your preferred email address
> <inpyt type=email autocomplete=username> - your username on this site,
>                                            not your preferred email
>                                            address
> <input type=url autocomplete=username>   - OpenID

This seems reasonable.

I've filed a bug to track this:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237

It needs multiple vendors on board to make progress.


> Also, consider the case of login forms without username fields. You see 
> this sort of thing a lot these days, when sites remember who was last 
> logged in:
> 
> <form>
> <label>Password for hober: <input type=password name=pw></label>
> <p>Not hober? <a href=...>Click here to sign in</a>.
> </form>
> 
> It's difficult for tools to manage the user's auth info for such pages. 
> How can tools discover what the username is? The obvious solution, in a 
> world with autocomplete=username, would be to add <input type=hidden 
> autocomplete=username name=username value=hober> to the form.

So far, autocomplete="" hasn't applied to <input type=hidden>. This would 
be a bit weird, giving it a different meaning than usual (providing 
information to the UA, rather than getting information from the UA). I'm a 
bit skeptical of this kind of overloading.

Not sure what the right solution is, though.


On Fri, 7 Mar 2014, Garrett Casto wrote:
> 
> Another related issue that would be nice to address would be allowing 
> sites to positively assert that authentication succeeded. For sites that 
> authenticate client side via XHR, standardizing something like 
> window.external.AutoCompleteSaveForm() would be very helpful. For sites 
> that validate server side, I'm less sure what the correct avenue to 
> convey this information would be (response code, header, ...). I'm 
> assuming that this will be more contentious than adding username and 
> password attribution and I don't want to hold that up, but I would like 
> to see opinions on this.

I actually have a similar problem with purely JS-handled forms even 
unrelated to credentials. Because the form is never really submitted (even 
if we reuse the submit infrastructure, we cancel the 'submit' event and 
handle the work on the JS side), there's never an indication to the UA 
that it should save the fields, and so autofill never works right on these 
forms, even for things like postal addresses or e-mail addresses.

For the pure JS case, an API (probably on the <form> itself) would make 
sense and seems relatively easy. I've filed a bug on this:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238

For the real submission case, I guess what we want is a way to say 
"autocomplete=off" after the fact, basically. An HTTP header seems like 
the most obvious solution.

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239

Again, these need multiple vendors on board to make progress.


On Mon, 10 Mar 2014, Evan Stade wrote:
> 
> Currently, requestAutocomplete lets a user agent provide the same user
> experience across multiple sites for common data input flows. A site
> describes the data it desires (via a form and autocomplete attributes), and
> the user agent uses this information and what it knows about the user to
> expedite data input. For example, if one of the form elements has
> autocomplete=”cc-number” the browser might provide an experience tailored
> for a payment flow, or if there’s an element with autocomplete=”bday” the
> browser might use an experience that’s tailored for sharing identiy.
> 
> We’ve found that there are some details of the interaction which might
> affect the UX which cannot be inferred from the data inputs. We propose to
> add an optional argument to the requestAutocomplete method. Thus invocation
> would look like:
> 
>     form_element.requestAutocomplete(details);
> 
> This |details| argument would be an object where key-value pairs provide
> additional details regarding the request. The spec should define a set of
> keys and associated data types which are recognized. There are currently
> two key-value pairs we would like to add:
> 
>     key: “transactionAmount”
>     value: number
>     description: For data that is going to be applied towards a
> transaction, the /maximum/ value of the transaction. The browser does not
> guarantee that the returned payment instrument will work, but keeping the
> transaction under this amount will increase the likelihood of receiving a
> valid card number.
> 
>     key: “transactionCurrency”
>     value: string
>     description: a valid ISO 4217 currency code that describes the currency
> for transactionAmount. If not provided, the default is “USD”.
> 
> Justification? There are upper bounds on certain payment instruments, 
> for example different credit cards have different credit limits; a debit 
> card is linked to a bank account with a certain balance. It’s a much 
> preferable user experience to be able to catch these problems earlier 
> rather than waiting for the merchant to attempt the transaction and have 
> it fail (or have a user’s account overdrawn). Concretely, Chromium wants 
> to handle transactions over $2000 differently from transactions under 
> that amount.
> 
> Does this seem reasonable?

The requestAutocomplete() API is a Chrome proprietary feature right now so 
it's sort of acadmic, but:

Why would this only apply to requestAutocomplete()? Surely it would be 
just as important for the case where the user agent is filling in a form 
without using that API.

Also, I don't understand how these are supposed to work. How is the 
browser supposed to know the balance on my credit cards or bank accounts? 
How is the browser supposed to know which of my cards are good for USD and 
which are good for GBP?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'