[whatwg] validationMessage

[Tab Atkins Jr.]

On Thu, Feb 11, 2010 at 9:29 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> Do you know of any actual authors who would want to use
> validationMessage?  If there are any authors here who would want to
> use the validation API with their own UI, would you want to use
> validationMessage or write your own messages?  I wouldn't be likely to
> write my own UI at all, so I'm not the best person to have an opinion
> here.

When I use a jQuery validation plugin for my forms today, I pretty
much always rely on the default error message that the library
provides.  It's rare for me to override it; I typically only provide
messages when I'm specifying a custom validation that doesn't have a
message (as the default error message for a custom validation rule is
far too generic).

So yes, I'd use validationMessage in my own UI.  It's easier, as it
lets me be completely agnostic about the actual error, and just plug
in whatever the error is into my custom UI.

> More generally, however, who says the UA will provide actual text for
> all validation errors?  I'm not sure what a concrete example would be,
> not being particularly good at UI, but I could imagine UAs using some
> non-textual cue if you try to submit a form with a missing required
> input, say.  They could provide some artificial string in that case,
> though, I guess.

I don't know that I've ever seen a validated form rely solely on
non-textual UI for anything, except possibly the failure to fill out a
required field (and even then, there's a message somewhere on the page
explaining that all the fields with a red border are required or
whatever).

If that were to happen, though, an artificial string would be
appropriate.  Ian, do you think this needs to be explicitly stated?

On Fri, Feb 12, 2010 at 12:40 AM, Peter Kasting <pkasting at google.com> wrote:
> I am explicitly opposed to the UA showing validation messages to the user.
>  I do not think HTML5 should attempt to address use cases where the author
> wants the UA to show the messages.  I think the design should provide the
> author with return values that indicate what the results of validation were
> and the author should provide the rest of the UI.  In other words, I am
> opposed to trying to solve use cases #1 and #2 above.  Any design that
> attempts to solve them is a mistake.  Please remove validationMessage from
> the spec.

I *strongly* disagree.  #1 is by far the MOST important use-case for
these features, in my opinion.  Without it, several of the new input
types and attributes are basically useless.

Just as important, requiring the author to handle the UI means that
accessibility will likely be impaired.  I'm very excited about the new
types and error messages making my forms significantly more
accessible.  When you can provide accessibility like this *for free*
with no author intervention, it's silly to pass up the opportunity.

~TJ