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.
> 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.
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!
> 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.
They seem to have fully understood and carefully weighted the implications.