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.
