[whatwg] Form element invalid message

[Mounir Lamouri]

On 12/29/2010 07:41 AM, Ian Hickson wrote:
>> One way to do this would be to make the "invalid" event implement an 
>> interface with a function like setCustomErrorMessage(in DOMString 
>> message). This string would then be displayed by the UA in its UI 
>> wherever it displays validation error messages.
>>
>> I actually think that the customerrormessage attribute that has been 
>> suggested is a decent solution too. It does mean that you have to do 
>> some trickery if you want to display different error messages for 
>> different types of errors, but nothing too bad. All you'd need to do is 
>> install an event handler for the "invalid" event, and in that handler do 
>> something like element.setAttribute("customerrormessage", myMessage);
> 
> If you're setting an error message, what's wrong with setCustomValidity()?

setCustomValidity() means "this element is invalid for custom reasons"
and the argument is the error message. I think the use case of
setCustomValidity() is *checking* something on oninput, onchange or
other events and, if the condition is not fulfilled, call the method to
make the element invalid. For example, two passwords fields have to be
the same.

The customerrormessage attribute would have different use cases. It
would be when the element has known reasons to be invalid but when the
author want to override the UA string. I see two reasons for that:
1. the element has very complex rules like: <input type='email'
name='username' required maxlength="100" pattern="[^@]*@company.com">.
It sounds hard for a UA to give one simple sentence for this situation
but the author can try something like "Please, enter your corporate
email address (max 100 chars)".
2. the author want a specific string to match the context of the
website. For example, when you want to log on Foo website, the author
might want to be sure you see "Please enter you Foo ID." instead of a
generic "Please, fill this field." for <input name='username' required>

For sure, you can use setCustomValidity() for both use cases but there
is a small semantic difference and a bigger work to do. Using
setCustomValidity() for these use cases would be a pain while using a
customerrormessage attribute would be quite straightforward.

--
Mounir