[whatwg] Form element invalid message

[Scott González]

2011/7/28 Jukka K. Korpela <jkorpela at cs.tut.fi>

> 28.07.2011 12:16, Scott González wrote:
>
>  I agree that it's extremely important to be able to define error
>> messages per error condition, but it's not necessary to code all data
>> checking in JavaScript to achieve that today.
>>
>
> It's not, but if you cannot set the error messages in HTML, what's the
> point? Doing everything in JavaScript is simpler, especially because you
> should anyway duplicate the checks - for example, using JavaScript to get
> the pattern attribute value and run the check in it, to deal with the many
> situations where the user has JavaScript enabled and the browser does not
> support the pattern attribute (but still includes its value into the DOM).


Doing everything in JavaScript is easier for developers, but an easily
configurable JavaScript plugin is easier for a very large percentage of web
content authors. A first pass might look something like:

$( "#age" ).validation({
    required: "You must enter an email address.",
    min: "You must be at least 13 to post nonsense on the web."
});

As for duplicating the checks anyway, I completely agree and I personally
just use JavaScript anyway. As one of the development leads for jQuery UI, I
can tell you that I have mixed feelings about all of the new features. As a
developer, I want to leverage as much of the semantics and information as I
can, but I also want complete control over the results of providing those
semantics and information. This generally means we want the attributes
without any of their actual functionality, which is a shame.


>  You can simply code the
>> error message by letting the browser do the validation, then using the
>> validity flags to set your own message with setCustomValidity.
>>
>
> Pardon? You would let the browser run the checks specified in HTML, then
> check the flags and turn an error to a custom error for which you can set
> the error message. This sounds like more complicated than doing it all in
> JavaScript, where you can directly do whatever error processing needs to be
> done. To make the HTML way a feasible option, the spec should define an easy
> way to set the error message(s) directly.


This is purely a suggestion of how to implement what I've described above.

There are essentially three choices (this applies to most new markup-driven
features):
1) Provide the information in the appropriate attributes and let the browser
do its thing.
2) Provide the information in a script and do everything via scripting.
3) Provide the information in the appropriate attributes, but handle them
via scripting.

#1 will never be as flexible as #3. #2 is a decent compromise and can be
made more flexible by allowing additional configuration via scripts. I think
the spec needs to make #1 as good as it can, but also do what it can to
encourage #2 over #3 where possible/reasonable.


>   I have a feeling you'll still end up with a few
>> shortcomings because you won't have control over the order in which the
>> checks are done, so you won't be able to specify which error message to
>> show when there are multiple errors.
>>
>
> Yes that would be a problem too, but a tolerable one. Besides, I guess the
> spec could say that the checks are carried out in the order in which the
> attributes are specified (though this admittedly deviates from the
> DOM-centric approach), and it could have yet another Boolean attribute that
> specifies whether all checks are carried out or the first failure aborts the
> processing. But more realistically, and more logically DOM-wise, the spec
> could simply define the order (e.g., required, maxlength, pattern) and
> specify that when a check fails, an error message is issued and further
> processing is suppressed.
>
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>