[whatwg] Form element invalid message

[Aryeh Gregor]

On Mon, Sep 20, 2010 at 6:38 PM, Shiv Kumar <skumar at exposureroom.com> wrote:
> 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

Which browsers are these, other than old WebKit?  These are clearly
bugs.  If the browser implements validation at all, it really has to
provide acceptable UI.

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

That doesn't seem cryptic to me.

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

The best UI would probably be to report the error for one form field
as soon as the user tries to navigate to the next, actually (as well
as the final check at submission that the spec mandates).  The idea is
that as more browsers deploy form validation, they'll come up with
good UI for it, and competition will cause the best UI to be copied by
all browsers.  Spec writers will probably not come up with good UI at
all -- it's a much better idea to leave UI decisions to each browser's
UI designers.  Currently all this is very immature (no browser has
good UI yet -- I think only Opera has UI at all), so it's best to just
not use it for now.

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

A simple attribute won't work, because many things can be wrong about
the attribute.  For instance,

<input type=number min=5 max=13 step=2 required>

should display different errors if the user tries to input 4, 6, 14,
and nothing.  The browser can do a good job at giving a useful error
here.  The only case where it can't is pattern="", and the title
attribute is reserved for the authors to provide error messages in
that case.

If you do want to override the browser's error messages, there are
JavaScript APIs provided for it.  It doesn't make sense to have
declarative APIs, because the error will generally depend on what
exactly is wrong with the input, so you have to test programmatically.

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

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#interactively-validate-the-constraints

It requires the UA to report at least one error at a time.  Again, UAs
are much better situated to come up with good UI than spec writers
here, so trying to get specific UI requirements added is a bad idea.
If UAs converge on some aspects of the UI at some future time and it's
worth enshrining those in the standard, we can do it then, but so far
we don't have any implementation with good UI, and shouldn't try to
predict what good UI would look like.