As for #1, there's a good reason why login forms shouldn't persist form state: it leaks information. Showing the successful username leaks information that that username exists. It also is a subtle, possibly incorrect, hint that the user typed their username correctly. It is just as likely that the user typed their username wrong, and as the number of users go up, the chance of a one or two character difference between usernames is increased. If the username field is filled in, users might realize that they entered it wrong and won't fix it, but rather just retype the password, the wrong password for the account given.
In the case of Yahoo's login form, the username is explicitly not echoed because people often have quite similar usernames, so they will try to login three times with the wrong username (it exists, it's just not their username) and then open a support ticket, etc.
(It's Yahoo. This is the single most-used piece of UI on Yahoo other than the front page. Do you really think we don't do it because we're lazy? We never got around to persisting the username in 14 years of endlessly recoding the login page?)
I thought I covered that, what follows the line you quoted is what I'm refuting.
But there's another reason not to have it persist depending on the style guide for forms on your site (you are using a style guide, correct?). The style guide may say that incorrect fields be called out as incorrect, using an icon or a red border or whatever; the correct fields are not called out and do persist their values, so you only need to change the incorrect ones. With a login form, the entire form is invalid, so do you persist the values in all the fields but indicate that they're all bad? This may require a change in your site's style guide, to acknowledge the existent of entire forms that could have invalid data and are not in an editable state, but it's does require not just blindly persisting the login name.
Comments
As for #1, there's a good reason why login forms shouldn't persist form state: it leaks information. Showing the successful username leaks information that that username exists. It also is a subtle, possibly incorrect, hint that the user typed their username correctly. It is just as likely that the user typed their username wrong, and as the number of users go up, the chance of a one or two character difference between usernames is increased. If the username field is filled in, users might realize that they entered it wrong and won't fix it, but rather just retype the password, the wrong password for the account given.
In the case of Yahoo's login form, the username is explicitly not echoed because people often have quite similar usernames, so they will try to login three times with the wrong username (it exists, it's just not their username) and then open a support ticket, etc.
(It's Yahoo. This is the single most-used piece of UI on Yahoo other than the front page. Do you really think we don't do it because we're lazy? We never got around to persisting the username in 14 years of endlessly recoding the login page?)
but regardless of whether the username is a correct one or not (in the database) - it should still persist in the UI.
I thought I covered that, what follows the line you quoted is what I'm refuting.
But there's another reason not to have it persist depending on the style guide for forms on your site (you are using a style guide, correct?). The style guide may say that incorrect fields be called out as incorrect, using an icon or a red border or whatever; the correct fields are not called out and do persist their values, so you only need to change the incorrect ones. With a login form, the entire form is invalid, so do you persist the values in all the fields but indicate that they're all bad? This may require a change in your site's style guide, to acknowledge the existent of entire forms that could have invalid data and are not in an editable state, but it's does require not just blindly persisting the login name.