[selectors-4] Replace :user-valid/:user-invalid definition with HTML spec

[josepharhar]

Fixes #9257

As suggested here, this definition is not up to par with the HTML definition and should be replaced by it: #9257 (comment)

[emilio]

Not sure editorially what'd be the best way to do this but the intention of the change looks good. @fantasai / @tabatkins could you take a look?

[emilio]

I think I'd probably do <a href="https://html.spec.whatwg.org/#selector-user-valid">in HTML</a>. or so (or using some bikeshed magic to get that), rather than dropping the raw URL there.

@tabatkins or @fantasai should look at this as editors, but lgtm for the general change, we shouldn't have two incompatible definitions of these.

[nt1m]

I suspect we'll want language like "are defined by the host language" along with a vague description of what the selectors are about.

[josepharhar]

Ok, I brought back the summary paragraph and said that its defined by the host language instead of html

[tabatkins]

Dropped a suggestion, and think we should restore the example, but after that r+

[josepharhar]

@tabatkins can we merge this?

[fantasai]

I think this approach doesn't do a good job of keeping a baseline definition for host languages that don't define their own rules. Let me see if I can come up with a sort of halfway step here...

[josepharhar]

Let me see if I can come up with a sort of halfway step here...

Happy to take any suggestions or a new PR

[dbaron]

So I think the existing definition that this is removing is a bit of a mess: it seems to talk about relationships between some of the other pseudo-classes (:invalid, :out-of-range, :required) that should perhaps be defined in the sections for those pseudo-classes but probably shouldn't be defined here.

I think the essence of these pseudo-classes is that they are subsets of :valid and :invalid that only match following certain user interactions that should call attention to the validity/invalidity, such as the user interacting with the control or the user attempting to submit the form. HTML mandates both of these; the text in CSS mandated only the second (submission) but not the first (interaction). The text in CSS also mandated a behavior that the HTML spec doesn't have, which is that they stop matching when the user interacts with the control again.

So I think perhaps the key things to add back to address @fantasai's concern are:

• making the parallel with :valid and :invalid more explicit again (but hopefully dropping the muddled bit about the other pseudos)
• explicitly mentioning submitting the form as a type of (or alternative to) significant user interaction with the control

Hopefully we're ok with dropping the bit about no longer matching when the user returns to the control, given that HTML doesn't say that. (Or do any engines implement that?)

[josepharhar]

Hopefully we're ok with dropping the bit about no longer matching when the user returns to the control, given that HTML doesn't say that. (Or do any engines implement that?)

Yeah I don't think this is a thing. I think that the only case we start matching these and then stop matching them is when the form is reset.

other pseudo-classes (:invalid, :out-of-range, :required) that should perhaps be defined in the sections for those pseudo-classes but probably shouldn't be defined here.

making the parallel with :valid and :invalid more explicit again (but hopefully dropping the muddled bit about the other pseudos)

Ok, I added a paragraph to the :valid and :invalid sections. How does it look?

explicitly mentioning submitting the form as a type of (or alternative to) significant user interaction with the control

I added a paragraph for this. How does it look?