3 ms·
I do not get from where it comes that it is a rogue developer. I have worked in many companies where developers make mistakes. And, it is always the ways of wor
by Hokusai 7y ago
I do not get from where it comes that it is a rogue developer. I have worked in many companies where developers make mistakes. And, it is always the ways of working, giving more priority to features than quality, and similar cultural attributes of the company at fault.
The only time I saw this being a rogue developer was a commit and run done by a guy on his last day.
It is easy to blame one person when actually is a systemic failure that needs to be addressed at the company level.
- londons_explore 7y agoI agree - and in fact, I think accusing this guy of being rogue is an unnecessary direct attack on him/her. They are just doing their job, and in this case, acting in what they believe is best way for users. Here on HN, it seems most disagree, but that is still no reason to accuse someone of being rogue. Headline should be "Google Chrome actively ignores HTML5 standard"
- jefftk 7y agoThe standard says "SHOULD", not "MUST". (Disclosure: I work for Google)
- craftinator 7y agoAnd not following the spec recommendation has gotten us... Here. Where Google is protecting users from both bad actors and good actors, whether the user likes it or not! The overwhelming response to this issue makes it clear that the heuristics used are simply not good ENOUGH. They can't accurately predict the best user outcome in a majority of situations. The Chrome team has wrenched the onus of autofill responsibility from all other developers, then fumbled it, badly. A good fix for this is to give the onus to the user. Popup toggle buttons, labeled: Autofill: Yes, No, Auto. This means we can all stop hating Chrome team for being patronizing, stop hating web devs for being unable to make their beautiful apps work in our godawful browsers, and start hating ourselves instead!
- azernik 7y agoSHOULD means you can ignore it in particular circumstances and with good reasons. Not all the time as a matter of UI judgment.
- bullman 7y agoWhere is this supposed "should"? From the spec - The autocomplete attribute represents either: a) autofill expectation mantle b) autofill anchor mantle If the input type is "hidden", then it is wearing the "autofill anchor mantle". IN ALL OTHER CASES (emphasis mine) it wears the "autofill expectation mantle" And what are the rules on "autofill expectation mantle"? "When wearing the autofill expectation mantle, the autocomplete attribute, if specified, must have a value that is an ordered set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or autofill detail tokens ... 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. (emphasis mine)" Per: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofilling-form-controls:-the-autocomplete-attribute https://html.spec.whatwg.org/multipage/form-control-infrastr...
- jefftk 7y agoThe "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."
- bullman 7y agoSo then the crux of the conflict: 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.