- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 10 Jun 2004 18:29:28 +0000 (UTC)
On Sun, 6 Jun 2004, Christian Schmidt wrote: > > - I am not sure, when setValidity() is expected to be set, but it should > probably be done in onchange or oninput. At the same time, an > appropriate error message should be generated and stored somewhere, so > that it can be displayed in oninvalid. How about adding an onvalidate > event, so that authors can encapsulate validation and error message > generation in one function? 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. > - And how about supplying a way to display a user defined error message > in the same way as the built-in error messages are? This could be done > by adding an errorMessage property to the event object whose value > initially is the standard error message for the current ERROR_* > constant(s). The errorMessage property could then be altered in the > above mentioned onvalidate event handler, either if the input fails some > user-defined validation, or if the author wishes to create a more > detailed error message than the standard error message (it is hard for a > computer to explain a user, why their input doesn't match a particular > regular expressions). If validity is 0 when errorMessage is set, perhaps > validity should automatically be set to ERROR_USER_DEFINED. 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? > - The table in section B specified that the pattern attribute applies to > <input type="pattern">, but password is not among the types mentioned in > the first paragraph of section 2.9. (I assume you mean type="password".) Oops. Fixed. > - It may be relevant to specify how to deal with IDN domain names in > <input type="email"> and <input type="url"> - should they be allowed, > converted in the client or sent to the server in their original > character set? Good point. I think they should be sent in the original character set, since they are likely to be redisplayed, e.g. in profiles, right? I've added a note to this effect in the spec. > - With respect to <input type="email"> and <input type="url">, it may be > relevant to explicitly specify, whether any syntactically valid email > address/URI should be allowed, or if the client may/should also try to > determine whether the email/URI is live and working, e.g. do DNS > lookups. In practice, a lot of users seem to have trouble remembering > even their own email address, so sometimes it is useful with as many > sanity checks as possible. UAs should be allowed to do such checking, sure, but I don't want to require that e-mail addresses and URIs be valid, I know I've often given bogus ones myself... :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 June 2004 11:29:28 UTC