Hacker News new | ask | show | jobs
by Cldfire 1915 days ago
> One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username.

Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/multipage/form-control-infrastr...

> an input element whose type attribute is in the Text state that is followed by an input element whose type attribute is in the Password state

> New autofill field name: "username"

The intent isn't to pick a field far away in the DOM, though, so any autofill implementation doing that isn't being restrictive enough.
3 comments
hombre_fatal 1915 days ago
Nice note. One problem is that you are left without options, only hacks, to work around this heavy handed behavior. It wouldn't be so bad if you could opt-out with autocomplete="off".

And even if it did work, a spec is always underspecified even for the password manager who wants to follow it 1:1, so even in a best case scenario, you don't have implementation consensus. For example, you would think password manager heuristics wouldn't look outside the current <form> to assume the username field, but some do on some browsers.

The end result is that if you have a need that isn't the general case, you end up having to trade away UX to cater to software.

link
colejohnson66 1915 days ago
> Note that this behavior is defined as part of the `autocomplete` standard.

Yes, but it’s my understanding that Chrome ignores this attribute because some website authors abuse it to disable autofill on the login pages because “security”. I’ve also seen some places disable pasting of a bank’s routing and account numbers because “security”. It’s actually more secure for me to copy-paste those numbers than type them because I can’t make a mistake then!

It’s a tough call because I hate when websites do that, but I also want them to be able to disable it in the right places for security.

link
asiachick 1915 days ago
Yes, and the point of putting in the standard is so that it's documented how to author your website. Unfortunately, some not insignificant number of UI/UX designers want to push their special flow on users and so we get these incompatibilities.

Hopefully the specs and expectations will evolve to the point that if your site doesn't follow the spec no one will use it. I can certainly imagine Apple/Google/Microsoft/Firefox having a semi-seamless sign up and failing to follow the standard means you plenty of users turn away

link
hombre_fatal 1915 days ago
The spec is underspecified for basic edge cases, like any spec, and it's very hard to have implementation consensus.

This stuff is supposed to improve the UX. Yet the reality is that even when building basic forms, every website has to test and solve the sort of problems shown in TFA.

How much of the spec does every web developer in the world have to read to know that password managers should or shouldn't try to fill in credit card expiry/cvv in a hidden input? Does the spec even say anything about that? 1Password will ignore a `display: none`, by the way. Can this be quick-fixed by ensuring hidden inputs also have `display: none`? That's something every website trying to consider good autofill UX gets to figure out themselves if they even care.

Unfortunately "just follow the spec" does very little to block off the rabbit holes you'll find if you try to perfect UX on even basic forms, else I might agree with you.

link