[whatwg] WebForms2 validity

[Sean Hogan]

Ian Hickson wrote:
> On Fri, 9 Feb 2007, Sean Hogan wrote:
>   
>> I might be missing something obvious, but...
>>
>> When are ValidityState properties updated? And when are CSS pseudo-classes
>> (:valid, :invalid, :in-range, :out-of-range) updated? 
>>     
>
> Continually (in particular whenever the constraints or the values change 
> -- the validity states are defined in terms of those values).
>
>   
Ok. But what's the use of checkValidity() on form-control-elements?
Isn't it just:
  function() {
    if (!this.validity.valid) this.dispatchEvent("invalid");
    return this.validity.valid;
  }

>> Many textual input form-controls would begin in one or another invalid 
>> state (valueMissing, patternMismatch) however authors would typically 
>> want CSS validity styles to apply only after checkValidity() - either a 
>> manual one or the automatic one performed by form-submission.
>>     
>
> Why?
>
>   
I would probably now agree that the default should be immediate 
application of :valid / :invalid styling which can worked-around with 
script. The opposing view (what I would have said a year ago) is...

I think that's the way it usually is now. More specifically:
1. It could be confusing to have :invalid styling on form-controls when 
the page first loads.
2. It could be distracting for the styling of a form-control to switch 
between :valid and :invalid while the user is typing into it.
3. It could be distracting for the :valid and :invalid styles to apply 
before the user tries to submit or explicitly requests the data to be 
checked.

#2 can be worked around using :focus. I can't see how #1 and #3 can be 
worked around without script.
A :validated pseudo-class that applied after checkValidity() is called 
or form-submission has been attempted would give some extra flexibility 
in the noscript scenario.