[whatwg] Form element invalid message

[Shiv Kumar]

Roger,

 

Yes, an error or errormsg attribute that one can set at the server side
since the message you’d want the user to see will most likely be determined
by business rules.

 

Spec-ing how UAs should display the message may be a bit much but we should
have a way of hooking into the validation process and overriding the
displaying of messages. Say an event called onaftervalidation for example,
(which is fired after all validations have been run), where the event could
provide a collection of elements that did not pass the validation logic.

 

>and that if it is: <input size="20" name="email" id="email" error=""
type="email" required>
>or if it is <input size="20" name="email" id="email" type="email" required>
>then the built in browser error message for type="email" should be shown?



Yes, then the browser should show highlight the error in the way they see
fit. As of today, they each (those that do support validation) have their
own way. Some simply highlight the field and others (Opera) show a box under
the field. But they each call out only one field at a time.

 

 

Shiv

 <http://exposureroom.com/> http://exposureroom.com

 

From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Roger Hågensen
Sent: Monday, September 20, 2010 7:03 PM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Form element invalid message

 

On 2010-09-21 00:38, Shiv Kumar wrote: 

Scenario 1:

We now have the option define if an element is required and the form will
validate the value such elements before submission. That’s a step in the
right direction. However, it so happens different implementation do
different things in the case when the validation return false.

 

Some browsers, have no visual indication (probably due to lack of support at
this time)

Some browsers will outline the field in question

Some will pop up a message under the field in question. The message is
something cryptic like “You have to specify a value”.

 

Scenario 2:

That’s one aspect I’d like to talk about. The other aspect is that
typically, you don’t want to show only one error as a time to the end user.
You want to show them all validation errors after trying to submit the form
one time (this is the common practice as well), rather than forcing them to
submit a form multiple times to discover validation issues one by one. As
you can imagine this is a nightmare for the end-user.

 

For the first scenario I’d like to propose that we have a validationMessage
attribute (or some other name) that allows web developers to specify a more
appropriate (based on the type of input data required and/or the input type
such as text, url, email etc.), user friendly/business friendly and creative
error message rather than some unknown message (as different vendors will
likely have their own verbiage). 

 

For the second scenario I guess the spec should be clear about validating
all fields? I’m not sure what the spec for this is (I can’t seem to find
anywhere that details the validation process for forms).

 

What are your thoughts on the above?

 


Hmm! Like a error="" attribute or something like that, which is shown
instead of a generic built in browser message?

Take this example http://www.quirksmode.org/dom/error.html


I assume you wish to be able to do this instead:
<input size="20" name="email" id="email" error="A valid email must be
entered!" type="email" required>

and that if it is: <input size="20" name="email" id="email" error=""
type="email" required>
or if it is <input size="20" name="email" id="email" type="email" required>
then the built in browser error message for type="email" should be shown?

This still leaves the question of where/how to display the error.
Some might want a Balloontip happening  when the field looses focus (this is
how the Windows OS does it) and saves the most IMO, the error text could be
shown then.

If the browser does not behave like that but only when pressing submitting
then marking the fields and perhaps provide a mouseover tip explaining the
error (the error text could be shown then)

Or the error text could be shown like in that example, but that wold require
a "errorfor" or similar to how label for behaves.


I think it would be just best to spec it so that a Balloontip with the
browser error message (or the input field's custom error message) is
displayed at the field loosing focus, and optionally keeping the field
highlighted until the input is acceptable, thus allowign the user to fill
out the rest of the form and fix the error last, and not allow submission
unless all errors are fixed obviously, and if no fields been filled and the
user tries to submit then all required fields would be highlighted, maybe a
default OS error "ding" should be played too.

I believe this is the best UI implementation as it's instant feedback based.





-- 
Roger "Rescator" Hågensen.
Freelancer - http://EmSai.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100920/184cbc9a/attachment-0002.htm>