The "should" is in the spec's description of how to interpret "off": "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 "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values."
In 4.10.18.7.2...
"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.
NOTE: In addition, when an element's autofill field name is "off", values are reset when traversing the history."
@jeffk - Ok, I now understand where you are getting this interpretation.
I think this is a dangerous interpretation (and perhaps it requires altering the spec to say must). Again Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. How else do you propose we do that, other than following 4.10.18.7.1.
My parent was saying Chrome was not compliant with the spec, but SHOULD directives are not mandatory and a User Agent may decide that it would be a worse experience for users to follow them.
Chrome is claiming that enough developers have marked fields as autocomplete=off in user-hostile ways that it shouldn't be respected, while many people here are making the case that conflicts with site-provided autocomplete and other issues push the other direction. That's how to have this discussion, not by pretending this SHOULD is a MUST.
(I don't work on Chrome and don't know any Google-internal anything about this)
Additional food for thought. Elsewhere, in 4.10.5.1.2 (Text (type=text))...
"If the element is mutable, its value SHOULD (emphasis mine) be editable by the user. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the element's value."
If a browser offered a user a way to edit immutable fields, or blocked users from editing mutable fields, the discussion should be "is whatever reason they're doing this for strong enough to outweigh the presumption that following the web developer's request is the right thing to do". Not "the spec prohibits it, no matter how good your reason may be".
For example, you can use the browser's devtools to edit an immutable field, because "allowing someone to develop the site" is a strong enough reason.
In 4.10.18.7.1...
"The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values."
In 4.10.18.7.2...
"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.
NOTE: In addition, when an element's autofill field name is "off", values are reset when traversing the history."
@jeffk - Ok, I now understand where you are getting this interpretation.
I think this is a dangerous interpretation (and perhaps it requires altering the spec to say must). Again Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. How else do you propose we do that, other than following 4.10.18.7.1.