> Take it up with the standards body then.

But, in the standard, the autocomplete attribute is a hint to the user agent, not an authoritative direction. [0]

The people who want to make it an authoritative direction ought, as you say, to take it up with the standards body.

[0] https://html.spec.whatwg.org/multipage/forms.html#autofill : "User agents sometimes have features for helping users fill forms in, for example prefilling the user's address based on earlier user input. The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature." (emphasis added)

Yes, and every developer who understands what autocomplete="off" is supposed to do uses it with the expectation that browsers listen to that hint.

Google directly breaks developers' intentions. Chrome literally breaks implementations by ignoring this attribute that every browser respects - including previous versions of Chrome. Enabling autocomplete when it is explicitly disabled by a developer destroys UIs that provide their own replacement autocomplete functionality where it makes sense to do so.

Chrome is the worst with disrespecting developers' intentions. Even worse than this bug is the one where Chrome disbales autocomplete when specifically desired, if their broken "autodetection of login form" fails. I've had login forms, where we want the bloody autocomplete to work, not function because Chrome has their own algorithm for this shit rather than respecting the developer's wish to explicitly even enable it.

Later that same page says : "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."

(The word "should" has its own meaning in RFCs generally http://www.ietf.org/rfc/rfc2119.txt and in whatwg specifically https://wiki.whatwg.org/wiki/Specs/howto#Content)

3. 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.

They seem to have fully understood and carefully weighted the implications.

Key phrase "in particular circumstances". This is not particular circumstances, this is all inputs everywhere. The point of "SHOULD" is to allow some wiggle room for edge cases where matching the standard to the letter wouldn't make any sense, not to give browsers carte blanche to ignore SHOULDs as they please.

It's not all circumstances, quoted from TFA:

> We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2]

> In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.

> As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.

> [2] https://html.spec.whatwg.org/multipage/forms.html#autofill

I'm really confused here, they'll disable autocomplete on almost any setting apart from "off"?

If the problem is the web designers why isn't this just pushing the problem into the future where the top stack overflow answer is autocomplete="nochrome" or similar?

And what should I put to work cross browser? If chrome adds autocomplete when it's off and doesn't when it's set to a weird value, do other browsers do the opposite?

>And what should I put to work cross browser? If chrome adds autocomplete when it's off and doesn't when it's set to a weird value, do other browsers do the opposite?

This. Exactly this. Now you have an attribute value that works in some browsers and the exact opposite function in other browsers, and the only way to switch between it is server side rendering based on user agent or javascript attribute value modification based on user agent at render time. No option to have the browser choose functionality based on the markup alone. Welcome back IE6. We missed you. Thank Google for creating more Web Designer jobs!

Perhaps some more background is helpful.

> The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

So the other browsers are part of the WHATWG, and a new spec got defined. I don't see any problems here.

A mass-market web browser is a particular kind of user-agent with a particular target market and intended use; like any other specific application, it addresses a (potentially broad in an absolute sense) specific, particular set of circumstances compared to the scope of a standard.

Yes, "should" means "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."

From what I can tell, while one might disagree with how the Chrome team has weighed the implications (such things always involve subjectivity), they seem to have both understood and weighed the implications before making the decision.

> Take it up with the standards body then.

I'd like to, but I doubt they'll listen. As a compromise, I'd be happy to have browser developers allow me to ignore the more user-hostile parts of the spec.