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

[whatwg] Form element invalid message

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 29 Apr 2011 16:10:55 -0700
Message-ID: <BANLkTi=Ft48tEYy0eKfifKOK3dwjWCTkLA@mail.gmail.com>
On Fri, Apr 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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.

It's quite common for webpages to display an error message in red
along with a red border or whatever.

For example, if I go to www.google.com and click on the "sign in" link
at the top, then without entering anything press the "sign in" button.
At this point the page displays a error message in red that says
"Enter your email address."

This is a better message than we as a browser could ever display. All
we could know is that it's a required field and that it's an email
address. We have no idea that it the users address that is requested.

In general it makes a lot of sense to want to display a different
message when the user has failed to enter a valid value in a field.
Clearly the user failed to enter what was requested the first time,
and so the context around the field was not enough for the user to
enter what was requested. Hence a more detailed description is
appropriate.

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

Consider the example above from googles login page. Here there are two
possible errors:

1. The field is empty
2. The field doesn't contain an email address

In both cases the message "Enter your email address." seems
appropriate. And it seems better than what we as a browser could
generate.

In general, it's often nice to provide the full set of constraints
once the user has failed to enter what was requested. Consider markup
like <input type=number min=3 max=7>. It's very frustrating for a user
to enter the value 1 and be told "The minimum allowed value is 3" and
then once the user adjust it to 10 get the message "10 is too high". A
much nicer experience is "A number between 3 and 7 is required".

In other words, often times a single static message which describes
all constraints works, no matter what constraint the user has failed
to fulfill.

Certainly, this isn't always the case. But if you do want something
more complex, you can always attach a oninvalid listeners which
dynamically sets the attribute to something appropriate. Or simply use
setCustomValidity(), though again this looses a little bit of
semantics.

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

No, Firefox 4 has been out a grand total of 5 weeks, so it's very
early still. But I think there are already lots of real world use
cases which would be helped by the suggested attribute.

/ Jonas
Received on Friday, 29 April 2011 16:10:55 GMT

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