[whatwg] Form element invalid message

[Ian Hickson]

On Thu, 28 Jul 2011, Ian Hickson wrote (I'm replying to myself here...):
> On Fri, 29 Apr 2011, Jonas Sicking wrote:
> > On Fri, Apr 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Wed, 29 Dec 2010, Mounir Lamouri wrote:
> > >> On 12/29/2010 07:41 AM, Ian Hickson wrote:
> > >> >>
> > >> >> I actually think that the customerrormessage attribute that has 
> > >> >> been suggested is a decent solution too. [...]
> > 
> > For example, if I go to www.google.com and click on the "sign in" link 
> > at the top, then without entering anything press the "sign in" button. 
> > At this point the page displays a error message in red that says 
> > "Enter your email address." [...]
> > 
> > In general it makes a lot of sense to want to display a different 
> > message when the user has failed to enter a valid value in a field. 
> > Clearly the user failed to enter what was requested the first time, 
> > and so the context around the field was not enough for the user to 
> > enter what was requested. Hence a more detailed description is 
> > appropriate.
> >
> > > I don't understand how such an attribute would work. Take <input 
> > > type=number> for example, with an explicit min, max, step, etc. How 
> > > would you know what value to put in the attribute? There are going 
> > > to be different needs when the control's value is too low, too high, 
> > > not aligned to a step, missing, etc.
> > 
> > Consider the example above from googles login page. Here there are two 
> > possible errors:
> > 
> > 1. The field is empty
> > 2. The field doesn't contain an email address
> > 
> > In both cases the message "Enter your email address." seems 
> > appropriate. And it seems better than what we as a browser could 
> > generate.
> 
> A text input field could have a number of error conditions:
> 
>    <label> Offer code:
>     <input type=text maxlength=8 pattern="[a-z1-9]+" required>
>    </label>
> 
> Suppose the code is printed as two groups of four characters, for 
> example something like "1A2B 3C4D".
> 
> The user could have entered the code with the space (the site doesn't 
> want the space). Or the user could have read an O as a 0 (the code never 
> has any zeroes to avoid that). Or the user could have forgotten to enter 
> the code. In each of these cases, I think you'd want a different 
> message.

That's why we have setCustomValidity().


> Anyway. 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. 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(value.match(/0/) ?
>                     'Codes contain no zeroes, only Os.' : '')"
>            validitymessage="Enter the code without spaces.">
>    </label>
> 
> If we add this, do you think it should be displayed with, instead of, or 
> replaced by the setCustomValidity() message, when both are given?

Thinking on this more, I think it would make more sense to do:

    <label> Offer code, without spaces:
     <input type=text maxlength=8 pattern="[a-z1-9]+" required
            oninput="setCustomValidity(value.match(/0/) ?
                     'Codes contain no zeroes, only Os.' : '')">
    </label>

Or:

    <label> Offer code:
     <input type=text maxlength=8 pattern="[a-z1-9]+" required
            oninput="setCustomValidity(
              value.match(/0/) ? 'Codes contain no zeroes, only Os.' :
              value.match(/ /) ? 'Please omit the spaces in the code.' :
              value.length != 8 ? 'Codes are 8 characters long.' : '')">
    </label>


On Thu, 28 Jul 2011, Jukka K. Korpela wrote:
> 
> 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 don't buy that at all. For the checks that the browser can do, it's fine 
for the browser to use its own messages, IMHO. The only reason we have 
anything for pattern="" at all is that pattern="" is the one case where 
describing the error automatically is non-trivial.


> > 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.
> 
> A dedicated attribute is much better. In particular, it does not 
> interfere with the existing use of existing attributes.

An advisory hint is exactly what title="" is for and exactly what we're 
talking about here. I don't see any interference at all, only leveraging 
an existing feature for its primary purpose.


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

I really don't see the need for that.


On Thu, 28 Jul 2011, 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. 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.

Certainly if people did do that with any frequency it would be worth 
considering adding a declarative way to do it, but so far I haven't seen 
people do that at all. In my own projects I've found myself quite happy to 
rely on the default messages that the browsers provide.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'