- From: Christian Schmidt <whatwg.org@chsc.dk>
- Date: Fri, 11 Jun 2004 23:04:36 +0200 (CEST)
Ian Hickson wrote: > I have changed the setValidity method to address your concern. It is now > setCustomValidity() and takes a string argument instead of a boolean. Thus > when you set the custom error bit, you are forced to give an error message > that the UA can then give to the user. Nice. > In addition to the setCustomValidity() method change above, I've also > added a validityMessage attribute that returns what the UA would report if > it was to report an error at that point. > > Does that address your two concerns? Not quite. My suggestion about adding an onvalidate event was to make it clear to authors when they should do their validation, and also to make the code easier to read and understand. The custom validation could be done in onchange or oninput, but that may turn out to be too often or too rare. One UA may choose to only do validation and display errors on form submission and when form.validate() is called, while another UA may do validation on every keypress (and perhaps show a check mark next to valid controls, and a small help icon that shows the error message in a tooltip). If validity is the sum of several ERROR_* constants including ERROR_USER_DEFINED and the UA only displays the error message related to one constant at a time, it would probably make sense to display the one set with setCustomValidity() first (it would probably be more specific than the standard messages). I don't know whether this behaviour should be required by UA's or even suggested in the spec. My suggestion about an errorMessage/validityMessage was primarily to allow authors to set the property, but reading it may also be useful. Christian
Received on Friday, 11 June 2004 14:04:36 UTC