[whatwg] Form element invalid message

[timeless]

Your 13 example is a good argument against splitting between markup
and script. If the minimum value is updated in the html but not the
js, you get confused users. - I've seen the results of letting logic
get out of sync from error reporting, it isn't pretty.

On 7/28/11, Scott González <scott.gonzalez at gmail.com> wrote:
> 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/>
>>
>

-- 
Sent from my mobile device