[ayberk]

These are all super nice and I really wish more developers made use of these, but my main complain is not having username and password fields on the same page :/

[jffhn]

>my main complain is not having username and password fields on the same page :/

This!

Our new Linux login has username and password entry fields in separate (and successive) windows, and they look quite similar.

Since I enter my password much more often (to unlock) than my username, I built up a reflex of entering the password, and the rare times I have to enter my username I often type in the password instead, visible to anyone looking at the screen.

I see this new design as a security issue.

[crazygringo]

That happens whenever certain usernames trigger different authentication pathways.

There's just nothing you can do about it if some users have passwords but other users have different authentication mechanisms.

[OJFord]

Of course there is, it can be on the same page (even hidden) up until the point it recognises a different mechanism is needed. Then browser autofill still works if the password is used.

I also have the opposite problem - sometimes I want Firefox to remember my username but not password; the only way seems to be to have it remember a dummy password (1 char so I recognise it as such) and then decline to 'update password' every time I change it in order to login.

[crazygringo]

> up until the point it recognises

But that's the point... how?

It recognizes that when the user confirms they've finished entering their username by clicking some kind of button.

At which point either a password box is shown or the alternative mechanism is shown.

There's no way to know in advance. And it's a UX problem if a password box is shown by default, because then users who don't have passwords think there's a bug in accessing the resource (because they don't have a password).

If your password manager has a problem with filling in the username, then the problem is with your password manager, not with the login flow. Starting with username-only is an industry standard for any product used in enterprises.

[OJFord]

> But that's the point... how?

Focussing on the next field or button.

> And it's a UX problem if a password box is shown by default, because then users who don't have passwords think there's a bug in accessing the resource (because they don't have a password).

Hence why I said it can be hidden.

> If your password manager has a problem with filling in the username, then the problem is with your password manager

For sure not filling username only is a problem/missing feature with Firefox, I didn't claim otherwise. My main use for this feature is not dealing with what I consider to be bad UX, but logging in to sites that for security I don't want FF remembering my password.

> Starting with username-only is an industry standard for any product used in enterprises.

That's the complaint.

[gsich]

>But that's the point... how?

There is so much JS, no problem.

Some suggestions: https://www.twilio.com/blog/why-username-and-password-on-two...

[pixelcort]

In the article they mention that:

> You definitely want to consider using these attributes if you are building a login form with the username and password on different pages.

[ljoshua]

Oy, me too, and though I love Twilio they are an offender here! What is the point of this pattern? Something to do with SSO validation or something?

[philnash]

It is to do with SSO. I will pass off to my Twilio colleague Kelley to answer this with a post she wrote last year: https://www.twilio.com/blog/why-username-and-password-on-two...

The nice thing about using autocomplete with username and current-password is that it can help your password manager auto fill these fields across pages if they are implemented like this.