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