Html: Autocomplete value for username OR user email address

[tigt]

Many login forms accept a username or email address to log in with. For example, GitHub’s login page:

<label for="login_field">
  Username or email address
</label>
<input type="text" name="login" id="login_field" class="form-control input-block" tabindex="1" autocapitalize="off" autocorrect="off" autofocus="autofocus">

I’m implementing a login form that does exactly this, but the spec doesn’t seem to address how to mark this up.

Should there be a value for the autocomplete attribute for this use-case, like autocomplete="username-or-email"?

• If a browser/password manager already has a username stored, but its heuristics would otherwise identify the first field as the user’s email, the autocomplete value could help disambiguate that either are acceptable, avoiding prompting the user. This also applies if the user’s email is already known, but the heuristics misfire in the opposite direction.

• Software could autosuggest (like how mobile keyboards do) a known user email even without an explicit <input type="email"> or inputmode="email". These attributes could have consequences since HTML form validation is not powerful enough for “either text or a valid email”.

• If the existing autocomplete=username value is sufficient for this use-case, depending on how you interpret what a “username” is, it would be nice to have a note in the spec saying so.

[tigt]

For example, Chromium has official advice for an “email-first” login flow. Its examples are… not very intuitive, which suggests that there isn’t an elegant way to implement this common login pattern using the current autocomplete attribute values:

<style>
  #emailfield { display: none; }
</style>
<form id="login" action="login.php" method="post">
  <input id="emailfield" type="text" value="[email protected]" autocomplete="username">
  <input type="password" autocomplete="current-password">
  <input type="submit" value="Sign In!">
</form>

[domenic]

The intent of the spec is that you can indeed have a username that happens to be of the form [email protected]. So using autocomplete=username makes sense. We can add a clarifying note.

[tigt]

Oh, excellent. Something like “the user identifier part of a login, usually a username, but also possibly an email address or ID number”? (My bank uses the latter)

[domenic]

I'm not a big fan of phrasing which implies that usernames are distinct from email addresses or ID numbers. I'd rather talk about how usernames come in many forms, sometimes with @ signs in the middle, sometimes all-numeric, etc.

[tigt]

Gotcha. And in the case of needing to disambiguate a username specifically, like in a signup form, that’s a job for autocomplete=nickname?

[domenic]

I don't know what you mean by "username specifically". If you mean "a username which does not allow numbers or @ signs", that seems like a job for pattern="".

[tigt]

Sorry for being unclear. I mean something like the screen name, like how you have domenic and I have tigt on GitHub.

[domenic]

Right. That's a username too.

[tigt]

So for something like this:

<fieldset>
  <legend>Account information</legend>
  <label>Username
    <input autocomplete="username? nickname?">
  </label>

  <label>Email address
    <input type="email" autocomplete="email">
  </label>

  <button>Change password</button>
  <!-- … -->
</fieldset>

Is nickname not correct? Or would that be for something like Twitter, where you have a @ username and a “display name”?

[domenic]

It is not correct. You should use autocomplete="username" for usernames.

[tigt]

Gotcha. I don’t think I understand the philosophy perfectly, so I can’t offer a sample note, but I definitely would appreciate a clarifying note.

[annevk]

@domenic the way nickname is defined could probably use some clarification too then; "screen name" and "handle" makes it sound like it could be your IRC nick.

(I also suspect it shouldn't matter as long as you're consistent within your site, but if the user has consistent usernames across sites, it might help if all sites used the same convention.)

[tigt]

Possibly relevant: Google Chrome’s dev console says this when encountering a login field without an autocomplete attribute:

[DOM] Input elements should have autocomplete attributes (suggested: "username email"): (More info: https://goo.gl/9p2vKq)

Is this dual-token approach compatible with your advice?

[annevk]

That does not match the requirements for an autofill detail token so that's rather bad if Chrome indeed supports that: https://html.spec.whatwg.org/#autofill-detail-tokens.

[tigt]

It’s even worse that they suggest it, then. Should I open a Chrome bug, or is this the sort of minor issue that requires a Googler to get on the radar?

[annevk]

@tigt please file a bug and (maybe) cross-link it. Would definitely be good to know if they don't follow the standard at all intentionally or if this was an oversight in the messaging.

[tigt]

Issue raised at Chrome bug #973,162.

[battre]

Thanks for raising this. I took a quick glance at the code and as far as I can see, Chrome would not interpret this correctly. We parse autocomplete attributes in two locations and both look for something that is more aligned with the spec.

[battre]

Chrome's change has landed. https://bugs.chromium.org/p/chromium/issues/detail?id=973162#c13

[annevk]

Great! So the main outstanding thing here is clarifying nickname I think: https://github.com/whatwg/html/issues/4445#issuecomment-477612310.

[tigt]

How about a note such as:

A username is any string used to identify a user; such user IDs can be of any syntax, and often double as other data such as email addresses, PINs, or phone numbers.

I don’t quite know how to word the disambiguation between nickname and username, but maybe if the intent is explained more clearly I can come up with something.

Lastly, do you think a sample login/signup form would be a good example for this part of the spec? It would have answered my question immediately, at least.

[domenic]

A note, and an example, sounds great to me! A pull request would be most welcome.

The example for "nickname" (Tim) vs. "username" (timbl) seems to make the intent fairly clear. For example, in Slack, my nickname (they call it "Display name") is "Domenic", whereas my username is [email protected], and my name is "Domenic Denicola".

[patrickhlauke]

I'm not a big fan of phrasing which implies that usernames are distinct from email addresses or ID numbers. I'd rather talk about how usernames come in many forms, sometimes with @ signs in the middle, sometimes all-numeric, etc.

coming in late, but: while you may not be a big fan of the phrasing, there are indeed sites out there in the wild that do make that distinction themselves - your account has a defined username, plus a separate email address, but they let you log in using either one.

some sites even go further and allow you to enter other "unique" (arguable) pieces of information...as an example, twitter's login currently has the first field allowing phone, email and username.

it would be nice to have a way to express the fact that a field can take various different (but equally valid) pieces of autocomplete/autofill content

[domenic]

coming in late, but: while you may not be a big fan of the phrasing, there are indeed sites out there in the wild that do make that distinction themselves - your account has a defined username, plus a separate email address, but they let you log in using either one.

Sure. In that case they would use both username and email autofill. My comment is specifically designed to clear up the confusion where some people though that they couldn't use "username" autofill when the username might contain an @ sign.

[annevk]

@domenic you cannot use both at the moment. autocomplete only takes a single value (it's multiple tokens, but it comes down to one value).

[domenic]

I was just stating that if

your account has a defined username, plus a separate email address

then those two fields would each use the appropriate autofill token.

[tigt]

I see @domenic’s point that username is completely valid for all use-cases described. What about the use-case of:

1. Browser encounters a field that accepts a user’s phone number OR email address OR screen name
2. Browser offers to autocomplete that field based on remembered information, suggesting both a remembered phone number and a remembered email address

Is there a way to express a hint for this useful (to me, anyway) behavior?

[annevk]

I don't think there is and that would require adding support for multiple values somehow

[tigt]

@annevk: After thinking about it, my use-case seems like it happens more for a sign-up form, which in the wild seem to be perfectly fine with multiple (sometimes optional) input fields, like so:

<input autocomplete=username required>
<input type=email required>
<input type=tel>

That said, my original use-case is valid for the case of shared devices/browsers with only partially-remembered information (autofill from OS knowledge, for example). If this ever comes up again, comma-separating autocomplete values a la srcset could work.

[mnoorenberghe]

For best results with current browsers (mostly referring to Firefox and Chrome), autocomplete=username should always be preferred for a field which can contain a username OR some other identifier (e.g. phone or email) for the purposes of logging in. There are a few reasons due to login and address (including phone numbers in that) forms being treated differently by browsers:

• Usernames are stored with a coupling to the site they were saved from whereas email addresses and phone numbers aren't. autocomplete=username suggests that the browser should suggest values relevant for this website whereas autocomplete=username may suggest all email addresses the user has saved which is less useful.
• Firefox and Chrome (at least when I checked about years ago) both have minimum field count thresholds before they do any autofill of saved addresses (though at least Firefox falls back to a totally different mechanism of Form History in that case). A login form containing only email and current-password fields doesn't cross that threshold as it contains only one "address" field so Firefox/Chrome don't suggest emails from address autofill when interacting with the username/email field.
• The use of email instead of username does risk telling the browsers not to fill a saved username in.

Btw. I would prefer that we suggest that nickname is for the offline sense of the word, not related to online accounts e.g.

• Given Name: Anthony / Nickname: Tony
• Given Name: Matthew / Nickname: Matt

Having to differentiate nickname vs. username is going to complicate things even more than they are now. I would even be fine with removing nickname if no UAs currently use it.

[micDropper]

For best results with current browsers (mostly referring to Firefox and Chrome), autocomplete=username should always be preferred for a field which can contain a username OR some other identifier (e.g. phone or email) for the purposes of logging in. There are a few reasons due to login and address (including phone numbers in that) forms being treated differently by browsers:

• Usernames are stored with a coupling to the site they were saved from whereas email addresses and phone numbers aren't. autocomplete=username suggests that the browser should suggest values relevant for this website whereas autocomplete=username may suggest all email addresses the user has saved which is less useful.
• Firefox and Chrome (at least when I checked about years ago) both have minimum field count thresholds before they do any autofill of saved addresses (though at least Firefox falls back to a totally different mechanism of Form History in that case). A login form containing only email and current-password fields doesn't cross that threshold as it contains only one "address" field so Firefox/Chrome don't suggest emails from address autofill when interacting with the username/email field.
• The use of email instead of username does risk telling the browsers not to fill a saved username in.

Btw. I would prefer that we suggest that nickname is for the offline sense of the word, not related to online accounts e.g.

• Given Name: Anthony / Nickname: Tony
• Given Name: Matthew / Nickname: Matt

Having to differentiate nickname vs. username is going to complicate things even more than they are now. I would even be fine with removing nickname if no UAs currently use it.

Could this be added to the documentation? I think having a field that accepts any of username, email, phone as an identifier in a login form is common enough to warrant some guidance.

[tigt]

@micDropper I’d be happy with that — my specific words on blocked on bureaucracy, so I can’t legally submit them yet.