3 ms·

Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c19 https://bugs.

Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c19 https://bugs.chromium.org/p/chromium/issues/detail?id=914451... https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164 https://bugs.chromium.org/p/chromium/issues/detail?id=468153...

antoinevg 7y ago
...which really makes it worse: 1. Our programming language has an attribute called "autocomplete" with two possible values: "on" and "off" 2. We will now (without consultation or announcement) simply start ignoring one of those values when you specify it. (and certainly not document the new behaviour!) 3. Here, I made you a convoluted (and undocumented!) workaround for getting the original behaviour of the attribute back. I'm not sure which horse these FAANG kids who excel at programming challenges rode in on, but this attitude is RIFE in their product SDK's and API's. Dijkstra must be spinning in his grave.
- mehrdadn 7y ago
  I'm reminded of an earlier comment: https://news.ycombinator.com/item?id=21083277 https://news.ycombinator.com/item?id=21083277
- tgv 7y ago
  All that based on an increase in page submissions. Is that the goal of auto-complete? The research behind the number (25%) is highly dubious, because the video cited as the source doesn't tell how it was done. At all. Ironically, it follows a section on how MDN is documenting the standards, and how that "contribute(s) a lot".
- mnoorenberghe 7y ago
  There are more than 20 different valid field name tokens in the spec, not just “on” and “off”[1]. If web developers actually used the other values correctly then user agents wouldn’t need to use heuristics to figure out the correct data to autofill. [1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#inappropriate-for-the-control https://html.spec.whatwg.org/multipage/form-control-infrastr...
Carpetsmoker 7y ago
> somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!
- Reelin 7y ago
  It's complicated. Sometimes website authors do silly things that negatively impact users; browsers ought to help (without breaking things!) where possible. Some daily annoyances that I wish browsers would actively mitigate, in no particular order: js-based redirects, blocking copy-paste, disabling text selection, hijacking the forward slash to open the website's own search function (I'm looking at you, Github), hijacking any of my other keyboard shortcuts that I rely on, creatively breaking my back and forward buttons (yes I realize there are legitimate reasons for some webapps), and overriding the built in right-click context menu.
  - Carpetsmoker 7y ago
    The things is that there are valid reasons for all those features: JS-based redirects are useful for many webapps, blocking text selection can be useful for some buttons and such, many people do use custom app-specific key mappings, overriding right-click is useful for many apps (e.g. Google docs), etc. etc. Of course, all those features can also be abused, but that doesn't mean it's a good idea to try and second-guess website authors; that just makes things much much more complicated for everyone. Any feature can be abused in any platform, and as the web has moved towards an "application platform" – instead of just a document viewing platform – there are many more features with potential for abuse, but it also becomes much more important that behaviour is consistent and predictable. I'm most definitely not on the "the specification is holy"-side of things, but from what I read in this issue the Chrome team seems surprising tone-deaf to concerns about Chrome's behaviour here. This is general patterns I see with Chrome, which confuses "it works for the majority of cases/users" with "it works well". These are simply not the same things.
    - 7y ago

antoinevg 7y ago

...which really makes it worse: 1. Our programming language has an attribute called "autocomplete" with two possible values: "on" and "off" 2. We will now (without consultation or announcement) simply start ignoring one of those values when you specify it. (and certainly not document the new behaviour!) 3. Here, I made you a convoluted (and undocumented!) workaround for getting the original behaviour of the attribute back. I'm not sure which horse these FAANG kids who excel at programming challenges rode in on, but this attitude is RIFE in their product SDK's and API's. Dijkstra must be spinning in his grave.

mehrdadn 7y ago
I'm reminded of an earlier comment: https://news.ycombinator.com/item?id=21083277 https://news.ycombinator.com/item?id=21083277
tgv 7y ago
All that based on an increase in page submissions. Is that the goal of auto-complete? The research behind the number (25%) is highly dubious, because the video cited as the source doesn't tell how it was done. At all. Ironically, it follows a section on how MDN is documenting the standards, and how that "contribute(s) a lot".
mnoorenberghe 7y ago
There are more than 20 different valid field name tokens in the spec, not just “on” and “off”[1]. If web developers actually used the other values correctly then user agents wouldn’t need to use heuristics to figure out the correct data to autofill. [1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#inappropriate-for-the-control https://html.spec.whatwg.org/multipage/form-control-infrastr...

Carpetsmoker 7y ago

> somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users And here I was, all along, thinking that website authors were in control of how their websites behaved. How silly of me!

Reelin 7y ago
It's complicated. Sometimes website authors do silly things that negatively impact users; browsers ought to help (without breaking things!) where possible. Some daily annoyances that I wish browsers would actively mitigate, in no particular order: js-based redirects, blocking copy-paste, disabling text selection, hijacking the forward slash to open the website's own search function (I'm looking at you, Github), hijacking any of my other keyboard shortcuts that I rely on, creatively breaking my back and forward buttons (yes I realize there are legitimate reasons for some webapps), and overriding the built in right-click context menu.
- Carpetsmoker 7y ago
  The things is that there are valid reasons for all those features: JS-based redirects are useful for many webapps, blocking text selection can be useful for some buttons and such, many people do use custom app-specific key mappings, overriding right-click is useful for many apps (e.g. Google docs), etc. etc. Of course, all those features can also be abused, but that doesn't mean it's a good idea to try and second-guess website authors; that just makes things much much more complicated for everyone. Any feature can be abused in any platform, and as the web has moved towards an "application platform" – instead of just a document viewing platform – there are many more features with potential for abuse, but it also becomes much more important that behaviour is consistent and predictable. I'm most definitely not on the "the specification is holy"-side of things, but from what I read in this issue the Chrome team seems surprising tone-deaf to concerns about Chrome's behaviour here. This is general patterns I see with Chrome, which confuses "it works for the majority of cases/users" with "it works well". These are simply not the same things.
  - 7y ago