W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Form element invalid message

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 29 Apr 2011 22:42:42 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1104292238590.19153@ps20323.dreamhostps.com>
On Wed, 29 Dec 2010, Mounir Lamouri wrote:
> 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)".

That's why the title="" attribute is used for the pattern message.


> 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>

Currently, Web sites rarely do more than simply focus the field and mark 
it in red or some such. Why would "Please enter your Foo ID" be so much 
better than "Please fill this field" or even just a big red arrow? The 
field presumably has a label right next to it, it's not like there's any 
ambiguity about what the user is going to need to type in there.


> 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.

I don't understand how such an attribute would work. Take <input 
type=number> for example, with an explicit min, max, step, etc. How would 
you know what value to put in the attribute? There are going to be 
different needs when the control's value is too low, too high, not aligned 
to a step, missing, etc.

Do you have an example of how this attribute would be used in a 
non-trivial situation?


On Wed, 29 Dec 2010, Jonas Sicking wrote:
> 
> I should also mention that we have implemented such an attribute in 
> Firefox 4 named x-moz-errormessage. We encourage authors to use this and 
> provide feedback regarding it's usefulness.

Do you know of any pages that use it? I would love to see this in the real 
world, it would help me understand the use case better.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 29 April 2011 15:42:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT