[whatwg] Comments on Web Forms 2.0 Working Draft

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'