:user-invalid & :user-valid browser support

[brandonmcconnell]

Description

Quoting the specification:

The :user-invalid and the :user-valid pseudo-classes represent an element with incorrect or correct input, respectively, but only after the user has significantly interacted with it.

The :user-invalid pseudo-class must match an :invalid, :out-of-range, or blank-but-:required elements between the time the user has attempted to submit the form and before the user has interacted again with the form element.

The :user-valid pseudo-class must match a :valid element between the time the user has attempted to submit the form and before the user has interacted again with the form element.

User-agents may allow them to match such elements at other times, as would be appropriate for highlighting an error to the user. For example, a UA may choose to have :user-invalid match an :invalid element once the user has typed some text into it and changed the focus to another element, and to stop matching only after the user has successfully corrected the input.

Rationale

There has been plenty of discussions and workarounds supporting this for over a decade now (or at least as far back as I can remember)— not so much the pseudo itself so much as clunky methods to accomplish what this pseudo would provide effortlessly.

• https://www.bram.us/2021/01/28/form-validation-you-want-notfocusinvalid-not-invalid/
• forms: validation. don't show errors until the user has had a chance to do something angular/material#1633
• Bug - Input - Validation - First time validation doesn't show error angular/components#7558
• Bug - Input - Validation - First time validation doesn't show error angular/components#7558
• https://stackoverflow.com/questions/40529817/reactive-forms-mark-fields-as-touched
• Angular's markAsTouched, markAsUntouched, markAsDirty, markAsPristine → https://angular.io/api/forms/AbstractControl
  • https://stackoverflow.com/questions/59885764/angular-is-there-a-way-to-markastouched-a-field-without-a-form
  • https://stackoverflow.com/questions/60759030/both-markallastouched-and-markastouched-dont-affect-subforms
• How to mark custom form control as dirty/touched? vmware-archive/clarity#3191

Oftentimes, we want to validate/invalidate form data, but we don't want to show the field as valid or invalid until after the first change event so the user has a chance to interact with the form field before the page applies successful/failure styling to the element.

Specification

https://w3c.github.io/csswg-drafts/selectors-4/#user-pseudos

Tests

• :user-invalid: https://wpt.fyi/results/css/selectors/user-invalid.html?label=master&label=experimental&aligned&view=subtest&q=user-invalid
• :user-valid: https://wpt.fyi/results/css/selectors/user-valid.html?label=master&label=experimental&aligned&view=subtest&q=user-valid

[foolip]

Looks like this is supported in Firefox, and these are the implementation bugs for Chromium and WebKit:
https://bugs.chromium.org/p/chromium/issues/detail?id=1156069
https://bugs.webkit.org/show_bug.cgi?id=222267

(Linked in BCD in mdn/browser-compat-data#17930.)

[annevk]

I wonder if whoever implemented these in Firefox can help out with whatwg/html#8452 as it's not clear how they work in terms of HTML. Selectors doesn't dictate the rules for host languages after all.

[jgraham]

Seems like @emilio did the Gecko implementation.

[emilio]

I mostly rejiggered :-moz-ui-{valid,invalid}, which were pre-existing. The rules are a bit complex, but I can try to explain them:

• For <button>, :valid and :user-valid are equivalent (code
• Seems like the same is true for form-associated custom-elements (code). That was implemented afterwards, maybe @EdgarChen can comment. Might be useful to allow authors to customize them.
• For <input>, <select> and <textarea> the rules are described in this comment. <select> code is here, <textarea> is here.

[annevk]

I think for this to be part of Interop 2023 someone would have to turn that into a PR against the HTML Standard. A lot of it looks somewhat straightforward, but some of the state keeping and when to invalidate that state might be tricky I suppose. And yeah, I suspect that for form-associated elements we need to reconsider when they would apply.

[foolip]

In the State of CSS 2022 question about browser incompatibilities, there was one mention of :user-invalid and one of :user-valid, so not enough to make the top list in #248.

(I'm commenting on all proposals where I could find some mention at all in State of CSS results.)

[foolip]

In the MDN short survey on CSS & HTML, "CSS :user-invalid and :user-valid pseudo-classes" was selected by ~11% of survey takers, putting it in the bottom third of the 20 options. (There is some uncertainty as with any survey data.)

[mfreed7]

I think for this to be part of Interop 2023 someone would have to turn that into a PR against the HTML Standard. A lot of it looks somewhat straightforward, but some of the state keeping and when to invalidate that state might be tricky I suppose. And yeah, I suspect that for form-associated elements we need to reconsider when they would apply.

I agree with this comment. It's tough to tell what the standardized behavior is or should be for this. E.g. there seems to be a lot of flexibility built into this sentence:

User-agents may allow them to match such elements at other times, as would be appropriate for highlighting an error to the user.

@emilio would it be possible to expand on your comment just a bit to summarize the behavior itself?

[foolip]

Thank you for proposing :user-invalid and :user-valid for gradients for inclusion in Interop 2023.

We are pleased to let you know that this proposal was accepted as part of the Custom Properties focus area. You can follow the progress of this Focus Area on the Interop 2023 dashboard.

For an overview of our process, see the proposal selection summary. Thank you for contributing to Interop 2023!

Posted on behalf of the Interop team.

[brandonmcconnell]

Thank you for proposing :user-invalid and :user-valid for gradients for inclusion in Interop 2023.

@foolip Just to confirm, this is unrelated to gradients

[foolip]

@brandonmcconnell sorry, of course, that was copypasta.