[whatwg] WebForms2 validity
shogun70 at westnet.com.au
Tue Oct 28 19:15:14 PDT 2008
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:
if (!this.validity.valid) this.dispatchEvent("invalid");
>> 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.
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
#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.
More information about the whatwg