[selectors] :autofill pseudo-class

[emilio]

See whatwg/html#6181 for the reasons why I think we should add this pseudo-class.

I think this is mostly uncontroversial, is there any reason people would think this is a bad idea / bad naming?

[Loirooriol]

Can you clarify what exactly it matches? Like if an <input> is autofilled, and then the user changes the value, does it still match?

[emilio]

That is to-be-defined in whatwg/html#6181, but it shouldn't match when the user edits the value. All browsers agree on that.

[Loirooriol]

css-pseudo is for pseudo-elements, this is a pseudo-class, so I guess it would be in selectors?

[heycam]

Would we also require that UA styling of autofilled form fields be done in CSS so that the author can override them?

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo?] :autofill pseudo-class, and agreed to the following:

• RESOLVED: : Add an :autofill pseudo-class to selectors

The full IRC log of that discussion

<dael> Topic: [css-pseudo?] :autofill pseudo-class
<dael> astearns: This is emilio who is likely not here
<dael> github: https://github.com//issues/5775
<dael> tantek: Are there particual concerns?
<dael> florian: GIven it exists and unlikely to be removed makes sense to have it. I'm wondering about privacy concern of it. Content of field isn't changed but if it is filled by a human or something saved might have privacy considerations
<dael> fantasai: I feel there are other ways to get that information. If all forms are filled in a second it is autofill
<dael> tantek: That does sound like a concern to raise. Sounds like :visited
<dael> florian: Yes, jsut thinking about it.
<dael> tantek: At a minimum I think it's excellent feedback. Maybe they can doc as potential privacy concern.
<dael> tantek: It would be good to get that as feedback from the WG
<dael> florian: I'll drop in GH
<dael> fantasai: Should we resolve to add the pseudo class?
<dael> astearns: Prop: Add an :autofill pseudoclass to selectors
<dael> RESOLVED: : Add an :autofill pseudo-class to selectors

[frivoal]

No strong objection to this, but just a note: I think we should consider whether there are privacy implications to this, and whether we should do anything to mitigate them. Whether a browser autofills something depends on whether a user as visited a site before or nor, whether the user has saved some information for that particular type of field or not, etc. This feels like a (small) source of information about the user, as well as a potential source of finger printing.

Admittedly, as @fantasai pointed out, sites can already infer that information by looking at whether forms field have been filled in withing less than 1 second of loading the site or something like that. At the same time, this would offer an easier way to access that information, which would work even when JS is turned off.

This is probably not a fatal flaw, but it seems worth considering.

[emilio]

I think at least Gecko doesn't auto-fill without user action, which mitigates the fingerprinting risk here, AIUI.

[emilio]

Ok, I think the spec work here should be done in html. @frivoal do you need the issue open for the privacy tracker bits? Otherwise maybe we should close this.

[emilio]

Oh, I guess we do have duplicate definitions for a bunch of these pseudo-classes in html/selectors...

[yisibl]

After removing the prefix, can the user overwrite the browser's default style?
https://stackoverflow.com/questions/2338102/override-browser-form-filling-and-input-highlighting-with-html-css

[jdragonbae]

I think at least Gecko doesn't auto-fill without user action, which mitigates the fingerprinting risk here, AIUI.

@emilio:
Hello, emilio.
I wonder the meaning of that Gecko doesn't auto-fill without user action. Could you let me know more detail about this one? The firefox version (88.0.1) seems to auto-fill without user action like Chromium.

[Iconejey]

I guess you are talking about styling inputs when the browser/user uses autocomplete, right? There already is a pseudo-class in CSS using input:-webkit-autofill but the code often gets ugly:

input:-webkit-autofill {
  -webkit-text-fill-color: white;
  -webkit-box-shadow: 0 0 0 30px lightblue inset;
}

Having to deal with -webkit-text-fill-color and -webkit-box-shadow to change text and background colors is counter intuitive in addition to being hard to make it work on browsers like Chrome where you have to deal with the browser's default styling and make everything !important.

An :autofill pseudo-class in my opinion is a great idea if browsers allow us to do something like this:

input:autofill {
  color: white;
  background-color: lightblue;
}

I found some documentation on developer.mozilla.org with a code example using :autofill but I couldn't find when the article was published. I tried using it in Chrome 90.0.4430.212 but it didn't recognise it (neither did VS Code).

Edit:

I found the use of :-moz--autofill but still not standard.
Also, there is a reference to :autofill on:

• wiki.csswg.org in the CSS4 specs witch says "not yet implemented".
• html.spec.whatwg.org.

On caniuse.com the autofill pseudo-class seems well-implemented in most browsers but for most of them the -webkit- prefix is needed...

It would be nice if at least SCSS compiled :autofill as:

input:autofill,
input:-webkit-autofill {
  ...
}

And if the use of -webkit-text-fill-color and -webkit-box-shadow was changed to standard color and background-color attributes.

[emilio]

I wonder the meaning of that Gecko doesn't auto-fill without user action. Could you let me know more detail about this one? The firefox version (88.0.1) seems to auto-fill without user action like Chromium.

Can you elaborate? On Linux, on Nightly at least, what I see is that if I go to a page where I have credentials saved, I need to click on the <input> and then I get a dropdown with users which would autofill my user and password, like this:

I can ask around to see if it's somehow different across platforms or settings though.

[emilio]

Ah, I got an answer back. Apparently we do autofill without user interaction, but:

• Only if the origin matches exactly with the same domain (e.g., if you have a login for signup.amazon.com we won't autofill amazon.com, but we'll autocomplete).
• Only in non-private browsing mode.

This is also user-configurable via signon.autofillForms=false (it's true by default).

[jdragonbae]

Ah, I got an answer back. Apparently we do autofill without user interaction, but:

• Only if the origin matches exactly with the same domain (e.g., if you have a login for signup.amazon.com we won't autofill amazon.com, but we'll autocomplete).
• Only in non-private browsing mode.

This is also user-configurable via signon.autofillForms=false (it's true by default).

Thanks for the details. Should we any further discussion on privacy issues? I think the -webkit prefix has the same issue.

[yisibl]

@emilio The default style of input:autofill in Firefox can cause errors in some page styles. Is there a similar problem in the newly implemented WebKit?

https://login.taobao.com/member/login.jhtml

2021-07-05.10-48-07.mp4

[yisibl]

@Iconejey Yes, we now have to use a very hacky method to overwrite Chrome's default style, because box-shadow: none has no effect.

input:-webkit-autofill {
    -webkit-box-shadow: 0 0 0 1000px #fff inset;
    box-shadow: 0 0 0 1000px #fff inset;
}

See Chrome Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=951476

[fantasai]

Edited in. @emilio Let me know if this definition is missing anything?

I think :-webkit-autofill is covered in #5847 ?

[emilio]

@yisibl we don't use filter for autofill anymore, for what is worth.

@fantasai looks good, thanks!