[whatwg] Comments on Web Forms 2.0 Working Draft

to clarify this. does this mean that a control must constantly maintain 
it's "public" validity property? or that it should keep a "public" and 
"private" validity? where CSS settings are determined by the "private" 
value.

-dean

Ian Hickson wrote:

> On Wed, 23 Jun 2004, Christian Schmidt wrote:
> 
>>>>The custom validation could be done in onchange or oninput, but that
>>>>may turn out to be too often or too rare.
>>
>>Doing it on onchange will be to rare. If there is a CSS rule for
>>:invalid, this rule should be applied as soon as the value of the
>>control becomes invalid and not wait for the onchange event to be
>>triggered (right?).
> 
> 
> :invalid will apply to an element whenever it is invalid, yes.
> 
> 
> 
>>Doing it on oninput may turn out to be too often. Assume that I have a
>>validation function that takes, say, 0.2 seconds to compute. If this
>>function is called oninput, it has to be computed for each keypress and
>>that makes typing slow. The UA may choose to only do the validation once
>>in a while, e.g. once every x seconds, so that the :invalid rule is
>>still applied, just a little delayed. Or if there are no :invalid rules,
>>the UA may choose not to validate until e.g. form.validate() is called
>>or control.validity is accessed.
> 
> 
> The UA can do its own validation continuously (none of the WF2 built in
> validations are particularly time consuming), and the author can do the
> custom validation whenever he likes, either oninput, onchange, or using
> some sort of timeout triggered by one of those events.
> 
> Isn't that enough?
> 
> 
> 
>>Also, onchange and oninput are not triggered by scripted changes to the
>>control value. I think that an onvalidation event should be triggered by
>>scripted changes, so that control.validity is always in sync with the
>>actual validity of the control.
> 
> 
> It is, apart from the custom bit, which is set when the author sets it. If
> the author set the value, it's the author's responsibility to set the
> validity (or, e.g., he could call changed() on the control to trigger an
> event and have the validation on the event).
> 
> Generally though, it seems that the author would want to only set a
> control to a valid value... seems like bad UI for script to set a value
> and then later complain to the user that it isn't valid!
>

Received on Thursday, 24 June 2004 11:31:02 UTC