[whatwg] validationMessage

[Ian Hickson]

On Tue, 10 Nov 2009, Michelangelo De Simone wrote:
> 
> I've been dealing with the validationMessage implementation in WebKit. 
> As some of WebKit member pointed out it's quite unusual for an attribute 
> to "return a suitably *localized message* that the user agent would show 
> the user".
> 
> Couldn't such behavior be potentially heterogeneous among UAs and 
> localizations?
> 
> What is the rationale about this choice? A simpler behavior with a 
> predetermined list of return values (eg: i.validationMessage == 
> VALUEMISSING) could be much more efficient for authors and implementors 
> to deal with, IMHO.

The relevant use cases that led to this design are:

1. Getting validation of forms without scripting, with the UA doing all 
   the UI work.

2. Getting validation of forms with the UI designed by the author, but 
   with the actual validation work (including working out what the 
   messages should be) done by the UA.

3. Getting validation of forms with the UI completely done by the author,
   including deciding what the messages should be.

For #1, the DOM API is irrelevant, and the UI message is generated by the 
UA, so by definition it is localised.

For #3, the author generates the messages, so the error string isn't 
useful. Instead, the "validity" API gives the status of the control, down 
to each individual constraint, and the author can use that to generate the 
relevant error message.

For #2, the author can use validationMessage to get the relevant message, 
which it can then insert into its page dynamically.


On Tue, 10 Nov 2009, Scott González wrote:
>
> Wouldn't the UA be written for a specific language that would be 
> independent of the language the page's content is written in? For 
> example, a user in Spain would be using a UA with a Spanish locale (the 
> UA's menus, dialogs, button labels, etc. would all be in Spanish). If 
> that user were to visit a page written in French wouldn't the content 
> generated by the UA still be in Spanish? So an alert would contain a 
> message in French, but a button in Spanish. I would expect the same 
> thing to happen with validation messages.
>
> As for the suggestion of the validation message just being a constant, 
> you can just check the validity state if you want to provide custom 
> messages.

Indeed.


On Sun, 15 Nov 2009, timeless wrote:
>
> [GMail] apparently does expect localized buttons 
> <https://bugs.maemo.org/show_bug.cgi?id=5704> but in some cases the 
> buttons they expect are not the labels they want. We've had reports 
> where the gmail instructions mention OK/Cancel and the user had 
> localized (Yes/No) buttons. [...]
> 
> Trying to assume how the string is formatted or trying to guess which 
> strings describe the given buttons/actions by doing parsing is going to 
> fail.

Absolutely; that's what the .validity attribute is for.


On Fri, 20 Nov 2009, Michelangelo De Simone wrote:
> 
> pardon me but it seems almost nonsense to me: would users fill forms in 
> a language they can't even understand? For instance: I'm italian, I 
> speak Italian and English but I'm required to fill a form in Swahili. I 
> would understand validation messages for sure (they would come from my 
> UA) but I couldn't understand why they don't satisfy their constraints, 
> what I'm supposed to fill and when I should submit the form.

Indeed. This is the case today also. I don't think this API affects that.


On Thu, 19 Nov 2009, Peter Kasting wrote:
> 
> From https://bugs.webkit.org/show_bug.cgi?id=27959#c29 , where this was 
> implemented for WebKit: "This patch sure does seem to be an eloquent 
> argument for not having all these localized strings in the HTML5 form 
> element design! I don't see a lot of value of returning these strings 
> that might not even be in the same language as the website. I wish we 
> could get that changed." -- Darin Adler

How would we address use case #2 without this API?


> My oversimplified view of this is:
> * Providing a way for the webpage to specify validation constraints and 
> understand when they have not been met -- good
> * Directing the UA to step into this process and show the user messages 
> about the validation failures, which don't take into account context the 
> web page has -- bad

How would we do use case #1 without the second of these bullet points?


> This seems like an attempt to make life slightly easier on webpage 
> authors by providing boilerplate UI if they don't want to write 
> anything.  But I see that as a small benefit with significant edge 
> cases.  Authors are already expected to supply the textual content in 
> the page, the text in alerts, etc., so providing the text in the 
> "validation failed" UI doesn't seem that bad.  The UA can still do 
> things like turn fields red or add warning sign icons or something if it 
> likes.

I agree that we should handle use case #3, but that still leaves use case 
#1 at a minimum (unless we want to bail on form validation when script is 
disabled, but that seems to rather miss the point of the API).


On Thu, 19 Nov 2009, Scott González wrote:
> 
> I agree with this specific case because I would personally always 
> customize the validation handling. However, following that same logic 
> wouldn't you come to the conclusion that date inputs should not display 
> calendars because they need to be localized? I would certainly not 
> expect the average user to enter a valid date format of YYYY-MM-DD, so 
> not having a calendar would make validation of dates almost worthless 
> without a calendar. On the other hand, this is another case where I 
> would most likely use a library like jQuery to display a calendar anyway 
> to give me more control over the calendar. A bit off-topic, but they 
> seem to be pretty closely related.

I agree that it's similar. The whole point of these additions is to reduce 
the need for scripting.


On Thu, 19 Nov 2009, Peter Kasting wrote:
> 
> * I am confused, what needs to be localized about the calendar?  Are you
> referring to non-Gregorian calendars, e.g. the Mayan calendar?

On Fri, 20 Nov 2009, Scott González wrote:
> 
> Month names, day names, whether the year comes before or after the 
> month, etc.

Right.


On Fri, 20 Nov 2009, Michelangelo De Simone wrote:
> 
> validationMessage returns "something" in a localized fashion related to 
> UA's locale. This means that we have two major issues from my point of 
> view:
> 
> 1. decontextualization: page's locale may differ from UA's locale;
> 2. heterogeneity: actual specs rely too much on implementors and
> different localizations.
> 
> 1. Decontextualization
> 
> As I and Peter pointed out it's quite nonsense. Except for the obvious 
> difference between page content (eg: let's say "English") and validation 
> message content (eg: let's say "Italian"), it's most illogical: would 
> you ever fill a form in a language you don't understand just relying on 
> validation hints from your UA? Ok, let's say you accomplish such task 
> after N attempts: what do you THINK you're gonna submit? Perhaps you 
> thought to be filling a form to register to a forum while you were 
> unconsciously filling, instead, a "malicious" form.

This objection seems orthogonal to the use cases this API is intended to 
address. I don't think the case of pages being in another language are 
really relevant here.


> 2. Heterogeneity
> 
> Even if objections in 1. hadn't reasons to exist we would have a (de 
> jure) HTML spec with no common validation messages: UA X, in locale L1 
> would have some strings; UA Y, in the same locale, would have other 
> strings. It's not generic and it's not "ruled" enough.
> 
> Thus far there're much better ways to accomplish the same task; for what 
> it's worth, my opinion is that validationMessage has very few reasons to 
> exist at all.
> 
> UAs can come up with their own desired way of advising users of 
> validation errors and authors can enforce such communication in the way 
> they prefer: we all love ValidityState's validation flags.:)

That's fine for use cases #1 and #3, but it doesn't handle case #2, which 
frankly I think is likely to be the most common case -- people are going 
to want to style the UI, but they usually aren't going to want to 
reimplement all the validation logic. What's the point of having the UA do 
it at all if the page then has to redo it?


On Sun, 22 Nov 2009, Aryeh Gregor wrote:
> On Thu, Nov 19, 2009 at 7:05 PM, Peter Kasting <pkasting at google.com> wrote:
> > The UA can still do things like turn fields red or add warning sign 
> > icons or something if it likes.
>
> What's validationMessage even supposed to return in these cases?  For 
> instance, suppose that a particular UA never returns an error for 
> max/min overflows because it always just snaps the value to the max or 
> min onchange and onsubmit.  (AFAICT the spec permits this.)  What is it 
> supposed to return if a script queries the input's validation status 
> when it's temporarily invalid, like if the user changed it but didn't 
> move the cursor out of the input yet?  The spec just says "a suitably 
> localized message that the user agent would show the user", but in this 
> case the user agent wouldn't normally show the user anything.

It should show the same message it would give the user if the user hit 
"enter" to submit the form in this scenario.

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