Michelangelo De Simone
micdesim at gmail.com
Fri Nov 20 03:16:06 PST 2009
2009/11/20 Scott González <scott.gonzalez at gmail.com>:
> following that same logic wouldn't you come to the conclusion that date
> inputs should not display calendars because they need to be localized?
You're speaking about a very different scenario, use cases and data
types. Let's focus our discussion to validationMessage for now.
validationMessage returns "something" in a localized fashion related
to UA's locale. This means that we have two major issues from my point
1. decontextualization: page's locale may differ from UA's locale;
2. heterogeneity: actual specs rely too much on implementors and
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
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.:)
More information about the whatwg