2009/11/20 Scott González <scott.gonza...@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 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. 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.:) -- Bye, Michelangelo