W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

[whatwg] Form element invalid message

From: Scott González <scott.gonzalez@gmail.com>
Date: Thu, 28 Jul 2011 05:16:16 -0400
Message-ID: <CAO8i3icoUx_Fs+cZD3uCr2xQBFhEJ4m69x-D0S8QzE8V-oUDPA@mail.gmail.com>
On Wed, Jul 27, 2011 at 11:37 PM, Jukka K. Korpela <jkorpela at cs.tut.fi>wrote:

> 28.07.2011 03:21, Ian Hickson wrote:
>
>  A text input field could have a number of error conditions:
>>
>
> Indeed. Therefore it would be essential to be able to set the error message
> for _each_ check that a browser is supposed to do on the basis of HTML
> markup alone. If this is not possible, it is easier to authors to code all
> data checking in JavaScript. Setting the error messages is important both
> for context dependency and for localization (using the language of the
> browser's UI would be odd when it differs from the language of the page - if
> the page is in Greek and the instructions there are in Greek, I would expect
> the messages of the data error to be Greek, even when my browser speaks
> Hebrew).


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. 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. Since this is possible today, it's
probably worth building a prototype that reads the custom error messages out
of data- attributes, e.g., data-patternerror. 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. Perhaps the best you could
do is provide another option which allows multiple errors to be displayed at
once.


>  I guess we can have a dedicated attribute that user agents can use
>> to provide a message, rather than the current solution of just using the
>> title="" attribute for pattern=""'s error message.
>>
>
> The title="" attribute is generally supposed to contain an advisory title
> for an element, and deviating from this that way is very odd and confusing -
> especially since user agents may show its value in a tooltip or speak it out
> when entering the field.
>

I'd prefer not using the title attribute as well. In many cases where a
title attribute is already specified it won't make sense as an error
message. In cases where it will get specified specifically for pattern error
messages, authors will almost definitely use wording that doesn't make sense
for the title.

A dedicated attribute is much better. In particular, it does not interfere
> with the existing use of existing attributes.
>
>
>  If it's present, user
>> agents could use it to replace or augment their message, and authors could
>> make the message more specific by dynamically changing the attribute when
>> during the 'invalid' event handler.
>>
>>    <label>  Offer code:
>>     <input type=text maxlength=8 pattern="[a-z1-9]+" required
>>            oninput="setCustomValidity(**input.match(/0/) ?
>>                     'Codes contain no zeroes, only Os.' : '')"
>>            validitymessage="Enter the code without spaces.">
>>    </label>
>>
>
> It would be more logical and descriptive to call it errormessage rather
> than validitymessage.
>
> But the main problem is that attributes like maxlength, pattern, and
> required are supposed to provide some data validation in a simple manner
> that does not need to involve JavaScript and works even when it is disabled.
> To make them useful, it should be possible to set the error message for each
> of them separately in HTML.
>
> I have no better solution than to use separate attributes, like
> maxlengtherror, patternerror, requirederror. This doesn't sound cool, but it
> would work and would be useful.
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/<http://www.cs.tut.fi/%7Ejkorpela/>
>
Received on Thursday, 28 July 2011 02:16:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC