[selectors-4] Should :user-valid and :user-invalid apply to form and fieldset elements?

[josepharhar]

The selectors-4 spec says this here after the definition of :user-valid and :user-invalid: https://drafts.csswg.org/selectors-4/#issue-df919919

Clarify that this (and :invalid/:valid) can apply to form and fieldset elements.

I made a quick demo here: https://jsfiddle.net/jarhar/Lohxsz2n/30/
It looks like :valid and :invalid apply to form elements, whereas :user-valid and :user-invalid don't apply to forms. This behavior is the same across chrome, firefox, and safari.

Should we standardize this behavior which happens to already be interoperable? Or should we make changes to make :user-valid and :user-invalid apply to forms and fieldsets?

@nt1m

[nt1m]

The newly added HTML spec currently explicitly does not apply the :user-* pseudos on fieldset / form, I haven't really thought too much about this personally.

If we really wanted to define those pseudos on fieldset / form, they could be defined as the equivalent of :has(:user-invalid) or :has(:user-valid) for the respective elements. From an user experience perspective that probably makes sense, though status quo is fine too.

cc @pxlcoder @emilio Any opinions?

[emilio]

I think I have a slight preference for making form / fieldset never match these. The code tracking these in gecko is not amazing, I'm not excited about making it more complicated, and I've never seen a use case for these... But if there are use cases that need this I'd be ok supporting these.

I don't think it's fine to make these effectively :has(:user-valid) / :has(:user-invalid), however. That allows a form / fieldset to match both at the same time. Probably should be:

• :user-invalid matches if there's at least one :user-invalid associated element underneath.
• :user-valid matches if there's at least one :user-valid associated element underneath and there are no :invalid elements underneath or so (so :valid:has(:user-valid)?)

[josepharhar]

I'm happy to make :user-valid and :user-invalid not match forms and fieldsets. After all, this is already the interoperable behavior and we just need spec and tests for it. Nobody so far has really advocated for them applying to forms and fieldsets yet as far as I can tell.

I am adding a WPT here: https://chromium-review.googlesource.com/c/chromium/src/+/4839394
How exactly should we change the spec?

[emilio]

I think they don't match per spec already right? https://html.spec.whatwg.org/#selector-user-valid mentions it only matches input, textarea and select elements.

[josepharhar]

Yeah, we just need to do something about this note in the CSS spec: https://drafts.csswg.org/selectors-4/#issue-df919919
Since it's already defined as not matching in the HTML spec, should we just delete the note in the CSS spec? Or does the CSS spec also need to say which elements it matches?

[emilio]

Yeah, we just need to do something about this note in the CSS spec: https://drafts.csswg.org/selectors-4/#issue-df919919 Since it's already defined as not matching in the HTML spec, should we just delete the note in the CSS spec? Or does the CSS spec also need to say which elements it matches?

Why are these pseudo-classes defined in two places, incompatible with each other?

I'd remove the CSS spec section on these, or make it point to html, probably?

[josepharhar]

Sounds good, I opened a PR to do so here: #9308