Issue 914451: Autofill does not respect autocomplete="off"

This is not "war". Don't overdramatize.

Someone made a movie and called it that. It's not really a word. So yes, you proved words can be created. That however is an opposite process to the one that destroys the meaning of an existing word or expression through repetition by people who don't know how to use it. I'm against that kind of half-assery. Creation, art, those take work and discipline. And as much as creativity demands going against convention, you always first have to learn & be aware of what the conventions are. Not even doing that work, and then just claiming your way is just as legitimate as the accepted way for your own mere convenience, well it's a shortcut, and I mean in the best case you have a very slim chance of "just happening" to be a great artist, and in the worst case it's the height of ignorance and narcissism. So yeah I'm unimpressed. I would accept & respect even a deliberate act of transgression -- knowing the right way and doing it wrong on purpose -- before that kind of shoddy relativism.

I consider that similar to a bug in the browser or the operating system. Should the bank require that I only use specific browsers or operating systems? In fact any program I install on my computer could have a vulnerability, or be malicious and thus lead to my password being stolen. Should the bank require that I not install any programs except ones they specifically permit?

The bank should also consider which is more frequent: user account compromises due to weak/reused passwords, or user account compromises due to password manager bugs.

There are two fundamental problems.

First is the scrollbar thing I mentioned. It means that you can’t use it for layout purposes; you thought you could sit four blocks side-by-side with `width: 25vw`? (And that was pretty much the whole reason why people wanted viewport units in the first place—this being before flexbox provided alternatives that are generally acceptable, though not without flaws, or grid provided often better alternatives.) Sorry, that’ll only work on a platform with overlay scrollbars, not where scrollbars actually take up space. There’s fun history around Firefox’s implementation where they made it possible to get the “right” behaviour, but no one else implemented that, so it was eventually removed from the spec.

Secondly, it was also predicated on the idea that the physical viewport size won’t be changing all the time; but on mobile platforms where the address bar can get out of the way as you scroll that’s simply not true, so you’re stuck with browsers having to decide between two interpretations: vh picking either the smallest or largest value and thus not actually reflecting the viewport height half the time, or vh reflecting the viewport height and causing the page layout to jump around in a jarring fashion when the address bar expands or collapses, when vh is used as part of the layout.

The first can be fixed in two ways (which can be combined): firstly, by defining new units that exclude document element scrollbars (e.g. 100vw2 ≅ calc(100vw - env(scrollbar-layout-width-auto, 0px)), to define it in terms of what follows); secondly, by exposing the layout width of scrollbars to CSS, e.g. as env(scrollbar-layout-width-auto) for the width with `scrollbar-width: auto` and env(scrollbar-layout-width-thin) for the width with `scrollbar-width: thin`. These values would be something like 17px and 8px on Firefox on Windows, and 0px and 0px on platforms with overlay scrollbars.

The second, you probably need to expose new constants for the possible extreme values of viewport height. e.g. I could imagine env(viewport-min-height, 100vh) and env(viewport-max-height, 100vh) working, which would then allow developers to select one or the other, as suited their purpose. Or define new units opinionated on which value should be used, and then deprecate vw and vh since they’re inconsistently implemented.

(In using env(), I must caution that it’s currently rather broken for some sorts of situations: https://github.com/w3c/csswg-drafts/issues/3285.)

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