If some of the messages are localized and some are in language of the site that would be confusing.

(In reply to comment #1)
> If some of the messages are localized and some are in language of the site that
> would be confusing.

Specifications should recommend authors to override all error messages when they override one.
Though, this problem would happens as soon as a page is using .setCustomValidity() which might happen quite often for the password check use case (checking that both fields have the same value).

The mismatched language issue also happens if your browser-ui uses one language and you browse to a page which uses another language. In this case the page will be in one language and the error messages will be in another. I would even argue that this is likely to be a more common mismatch.

This suggested feature actually helps with that as the page author can be expected to use the same language in this attribute as on the rest of the page.

If we actually want that behavior should not we try to use localized strings based on the language of the page rather than based on the language of the browser?

And just as a sanity check, there is no use case for different error messages depending on what constraint was violated?

(Good point about localization being an issue for setCustomValidity() too. Forgot about that.)

(In reply to comment #4)
> If we actually want that behavior should not we try to use localized strings
> based on the language of the page rather than based on the language of the
> browser?

That would mean that browsers should provide localized strings in each languages they know? IOW, if a build is currently "One-language only", at least these string will have to be available in all languages. Seams weird to me.

> And just as a sanity check, there is no use case for different error messages
> depending on what constraint was violated?

Exactly. The idea is to prevent making things too complex (like having dozens of attributes). The author should be able to describe the requirement in one message.

(In reply to comment #4)
> If we actually want that behavior should not we try to use localized strings
> based on the language of the page rather than based on the language of the
> browser?

I suspect this is already allowed by spec and is basically a quality-of-implementation issue. However at least in firefox we only ship with one set of localized strings as things stand now.

I suspect this is something we'll look into in the future.

> And just as a sanity check, there is no use case for different error messages
> depending on what constraint was violated?

I would say there is. That was one of the issues I originally raised in the thread pointed to in comment 0.

However I think it's ok to start simple here and expand as we see need. One problem is that there isn't really a specified set of possible error messages. For example a browser could have different error messages for an invalid email address with a pattern, a invalid email address without pattern and an invalid email address that has required set.

In any case, with a bit of js-code this can be handled. In the event handler you can inspect the .value as well as the various properties properties on .validity and using that information set the new attribute to whatever you want.

I don't understand. The described use cases are exactly what setCustomValidity() is for. What is the problem with setCustomValidity()?

The problem is that setCustomValidity() makes the control invalid. For example it now matches :invalid.

The current problem is that the error message that the browser can come up with are fairly generic. For example for

<input type=email required name=username>

we can only provide vague wording saying that you must enter a valid email address. However the page generally knows exactly why a certain field is needed and can give a much better error message. For example:

<input type=email required name=username customerrormessage="Please enter your username. The username must be an email address where we can reach you.">


If you want to accomplish the same thing with setCustomValidity(), you'll have to do something like:


<input type=email required name=username oninvalid="setCustomValidity('Please enter your username. The username must be an email address where we can reach you.');" oninput="setCustomValidity('');">

But even here the browser might change the displayed error message as soon as the user start typing, if it is displaying UI at that time.

Well what would you do for, e.g., <input type=number> where there might be multiple different errors? (too low, too high, not on step, missing, etc)? Or <input type=text pattern required>, where it might be required or might not match the pattern?

We'd need one attribute per possible UA message, and we don't know how many UA messages there might be (e.g. the UA might also have different messages for combinations of errors, like a date field that is both too low and not on step).

The whole point of this feature is that the UA can do an excellent job of this, whereas the authors of most pages really just want to mark the control as required and not have to worry about it.

What I meant with respect to setCustomValidity() is that if you think you can do a better job than the UA, then you would do all the checks oninput:

   <input type=text pattern="..." oninput="check(this)">

   function check(control) {
      if (it's a text control) {
         if (it's required but the value is missing) {
            control.setCustomValidity('yo bro you need a value here man');
         } else if (it's got a pattern and the pattern doesn't match) {
            control.setCustomValidity('you need to make sure to write things correctly dude');
         } else {
            control.setCustomValidity('');
         }
      } else {
         ...
      }
   }

...and so on.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Requested feature seems redundant with existing features.

> The whole point of this feature is that the UA can do an excellent job of
> this, whereas the authors of most pages really just want to mark the control
> as required and not have to worry about it.

This does not match our implementation experience. I agree that of course any author would love it if the UA came up with a great error message for every situation. But as a UA we're forced to use very generic messages that can't be specific to the given control. For example we're forced to say "the number is too low" rather than "surely you don't have a negative age".

For now I suspect we'll implement the attribute and let authors experiment with it. In case people like it we'll reopen this bug (or file a new one against the next iteration of the spec)