2 ms·

> Every single labelled text input you ever create should have clickable labels. It’s a wonder this isn’t done by HTML by default This is done by HTML by defau

> Every single labelled text input you ever create should have clickable labels. It’s a wonder this isn’t done by HTML by default This is done by HTML by default, if you use the for="" attribute or nest the input in the label. > No user should have to guess at what the password requirements are. Show them when they’re relevant (P.S. And remove them when they’re not). Or, just always show them. It's hard to make them accessible if you can only see them when the field is focused. > Let users see their password This is arguably an antipattern. If this was a best practice, it would be baked into the browser. Encouraging password manager use (every browser comes with one built in!) is what we should be aiming for. "Confirm password" fields prevent the problem that the post tries to avoid, and it's really not "onerous". Or, use something like WebAuthn.

fomine3 5y ago
> If this was a best practice, it would be baked into the browser. Edge already support it for any password input. Yes it's better to be supported by browser, but it not mean not good to be implemented by website. How "Confirm password" solution better? It's completely redundant for password manager user. It also won't help from CAPSLOCK.
- bastawhiz 5y ago
  Password managers are already aware of confirm password fields. There's even an autocomplete attribute to annotate them (use autocomplete="new-password" twice). Caps lock is a problem even with the ability for a user to see their own password, because they need to take an additional action to unhide their password. Most users won't check, they'll just hit enter. And again, this is something the browser can (and depending on what you're using, already does) do—browsers have shown an icon or tooltip. On mobile, browsers briefly show the most recent character typed. There's no reason this couldn't be extended to desktop. And even in the very rare case where you goof with caps lock, there's a forgot password flow that lets you (hopefully) reset your password with the same number of steps as a good OTP flow (which is literally what password reset is). In almost all cases, this is even preferable to adding the complexity (accessibility, L10n, etc) of a "reveal password" toggle OR a confirm password field, because properly implemented it gives the user the chance to use a password manager a second time. It's absolutely bizarre to expect every single web developer to need to know and implement every possible best practice around password handling of this sort, when it could be handled by the (already semantically annotated) GUI control that the user agent implements.
  - fomine3 5y ago
    > On mobile, browsers briefly show the most recent character typed. There's no reason this couldn't be extended to desktop. I should against it. On mobile device, anyway we use software keyboard to input so we must hide display from others when input password. So displaying last character is harmless. OTOH desktop users sometimes can't hide their display from others, and they type via keyboard. So always displaying last character isn't good for security. Eye button for selectively showing password field is fine. Yes Caps is still problem if user never checked by clicking eye button, but still what's the point to adopt confirm field? I agree that ideally most developer don't have to care about that but browser should.

fomine3 5y ago

> If this was a best practice, it would be baked into the browser. Edge already support it for any password input. Yes it's better to be supported by browser, but it not mean not good to be implemented by website. How "Confirm password" solution better? It's completely redundant for password manager user. It also won't help from CAPSLOCK.

bastawhiz 5y ago
Password managers are already aware of confirm password fields. There's even an autocomplete attribute to annotate them (use autocomplete="new-password" twice). Caps lock is a problem even with the ability for a user to see their own password, because they need to take an additional action to unhide their password. Most users won't check, they'll just hit enter. And again, this is something the browser can (and depending on what you're using, already does) do—browsers have shown an icon or tooltip. On mobile, browsers briefly show the most recent character typed. There's no reason this couldn't be extended to desktop. And even in the very rare case where you goof with caps lock, there's a forgot password flow that lets you (hopefully) reset your password with the same number of steps as a good OTP flow (which is literally what password reset is). In almost all cases, this is even preferable to adding the complexity (accessibility, L10n, etc) of a "reveal password" toggle OR a confirm password field, because properly implemented it gives the user the chance to use a password manager a second time. It's absolutely bizarre to expect every single web developer to need to know and implement every possible best practice around password handling of this sort, when it could be handled by the (already semantically annotated) GUI control that the user agent implements.
- fomine3 5y ago
  > On mobile, browsers briefly show the most recent character typed. There's no reason this couldn't be extended to desktop. I should against it. On mobile device, anyway we use software keyboard to input so we must hide display from others when input password. So displaying last character is harmless. OTOH desktop users sometimes can't hide their display from others, and they type via keyboard. So always displaying last character isn't good for security. Eye button for selectively showing password field is fine. Yes Caps is still problem if user never checked by clicking eye button, but still what's the point to adopt confirm field? I agree that ideally most developer don't have to care about that but browser should.