3 ms·

Take it up with the standards body then. Presumably this came about because some framework or something started including bad default attributes, and then Chro

Take it up with the standards body then. Presumably this came about because some framework or something started including bad default attributes, and then Chrome responds by ignoring the meaning of the specification in order to "improve UX". But in the end what happens is that the specification becomes meaningless and we're back to the browser wars where you have no way of knowing how anything works except a continuous testing process to vet the veracity of the spec for any browser you are targeting, and of course this is subject to change on a whim by Google. Will it improve the UX? Maybe... if Google is correct in its unilateral assumptions. But one thing for sure is that as a developer this costs you time, and it hurts the most if you are a well-intentioned developer who is trying to make the correct choice for your specific use case.

dragonwriter 10y ago
> 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 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)
- nix0n 10y ago
  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 http://www.ietf.org/rfc/rfc2119.txt and in whatwg specifically https://wiki.whatwg.org/wiki/Specs/howto#Content https://wiki.whatwg.org/wiki/Specs/howto#Content)
  - dragonwriter 10y ago
    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.
  - tokenizerrr 10y ago
    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.
    - dandelany 10y ago
      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.
      - dragonwriter 10y ago
        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.
      - tokenizerrr 10y ago
        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 https://html.spec.whatwg.org/multipage/forms.html#autofill
- developer2 10y ago
  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.
ori_b 10y ago
> 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.

dragonwriter 10y ago

> 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 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)

nix0n 10y ago
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 http://www.ietf.org/rfc/rfc2119.txt and in whatwg specifically https://wiki.whatwg.org/wiki/Specs/howto#Content https://wiki.whatwg.org/wiki/Specs/howto#Content)
- dragonwriter 10y ago
  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.
- tokenizerrr 10y ago
  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.
  - dandelany 10y ago
    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.
    - dragonwriter 10y ago
      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.
    - tokenizerrr 10y ago
      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 https://html.spec.whatwg.org/multipage/forms.html#autofill
developer2 10y ago
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.

ori_b 10y ago

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