Imo, valid use case for autocomplete=off is "the developer of webapp wants it".
Literally that and nothing more.
Literally that and nothing more.
I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. We are arguing for following a guideline that makes sense. This is why we have the w3c, an organization that attempts to weigh the needs of user, developers, and browser maintainers.
if you would like to autofill the form anyway click"
i made it a little terse, but there has to be a way to make it succinct and human readable.
But I think in general, some kind of prompt or override would work. I absolutely agree that if a user wants to use the browser autocomplete functionality, they should have an option to do so. I have no understanding for websites that just want to disable autocomplete without replacement.
However the concerns seemed to be about autocomplete being incorrect or conflicting with application-provided lists. I can see how that leads to frustration and confusion with users.
The Chrome team seems to trust its algorithm to an amount where they don't seem to find it necessary to deal with incorrect results - a view which doesn't match reality apparently.
This was done by Microsoft by the old days, now it's Google. How ironic.
> When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.
RFC2119:
> SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
As I read it, this behavior may or may not be a good idea, but it is not a violation of the standard.
Disclosure: I used to work on the Chrome team at Google, but I have no particular knowledge of autocomplete.
> I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that.
GGP was literally arguing that: https://news.ycombinator.com/item?id=21239172
Should developer decide that fields are autocomplete off or green or show javascript warnings? Absolutely yes.
If user wish to change that, users thing. The browser/google has no business to be mediator here, second guess application they know nothing about and manipulate it.
The browser should be predictable, well specified and harmless. It should not force me to convert all ids into random strings just so that random data do not get prefilled in.
IMHO there are cases where autocomplete=off should be respected, and other times when it shouldn't be - it's certainly not as simple as saying always do or always don't respect it.
IMO the distinction could be made to not automatically fill when the autocomplete=off but instead add a button to let the user initiate it
<input type="password" name="other-users-password" id="other-users-password">...> This is the behavior in Firefox (since version 38), Google Chrome (since 34), and Internet Explorer (since version 11). - MDN
I was pretty sure that it wouldn't do anything except make the security team feel better.
Well, OP that I responded to literally argued that.
I agree the platform needs to expose useful features in a predictable manner for application developers.
But I'd much rather have browsers decide what's reasonable control over the user experience.
When the browser decided to ignore spec, it is not user agency at all.
The need for auto fill is extremely application specific and the action is quite often destructive. And it is developer who gets to be blamed for lost data.
It's pretty annoying that we have to make hacks for a client card page not to automatically assume you want to fill in your own details.
That a browser could reliably infer from context what the right information to insert into a field could be is one of those things that gives great demo and may even work more often than not, but it's a virtually impossible problem to solve comprehensively. Developers have plenty of valid reasons to disable autocomplete and autofill functionality. Taking that away from them and requiring an obfuscating workaround is tantamount to creating an invisible pseudo-standard.
Imagine what would happen if we decided to solve the scourge of signed-unsigned pointer value bugs in C++ by having the compiler virally assume unsigned variable typing for memory related operations based on variable name. It might feel like a quick fix to a widespread problem, but it would break down all over the place and would break the code of developers who A) followed the spec B) knew what they were doing and C), at least some of the time, were doing it for a specific purpose.
These sorts of changes remove the incentive to write standards compliant code, leading to a mangled universe of hacks, quirks, and, in the end, bugs.
YouTubeTV uses feature policy to disable the browser's picture-in-picture feature.
So it's a good thing in that situation when the browser ignores the attribute.