On 20/01/2012, at 1:33 PM, Bronislav Klučka wrote: > On 20.1.2012 1:29, Jukka K. Korpela wrote: >> >> Why would things suddenly change when it comes to user interface? Besides, >> there is nothing in CSS as currently defined that even tries to address such >> issues. >> >> Yucca > > I've joined this discussion to point out the difference between presentation > and data behind it. But I agree, this has nothing to do with CSS, this should > not be handled by CSS. I'd prefer lang attribute here: if not presented > (directly on input element) then users OS locale should be used (or maybe > some general browser settings), if presented, format defined by that locale > should be used (the same process should apply to date inputs as well). > > Brona
The lang attribute is the structural declaration of the content's localization, be it prose or data values. There should be no difference in what the following mean: <p lang="en">This is some english text</p> <input lang="en" type="text" value="This is some english input"/> <input lang="en" type="date" value="2012"/> <!-- An english date --> This methods allows for an element-by-element application of localization enabling multi-lingual pages to exist. Added to the hierarchical resolution of language tags and this enables effective declaration. Add the <meta> tags and http headers and you have a compete resolution algorithm. Only once all of these avenues have been exhausted does the resolution of content language enter an ambiguous state whereby a user's default preference should be used. Do not forget that the UA specifies a user's preference in the Accept-Language header. If a server is incapable of providing a localized representation then what is returned is the most relevant representation available and as a result the one that the user has requested to see. It is up to the server to define the representation of a resource based on all request information and it is the UA's responsibility to render *that* representation for the user. There is a usability case for the UA to translate the content automagically for the benefit of the user, but this is assuming that the user desires this feature and is not multilingual and just navigating to a foreign site. For them to have to adjust their locale settings each time they do this is a disaster. Automatic translation as an option is better as it could be applied for white\black-list configured languages and will take responsibility for translating the entire content (or potentially translate="yes" elements) and not just form inputs. The method for how to handle data entry on inputs should be defined by the resolved language of the element per the algorithm. This is the only method which makes sense especially if you examine use cases for text entry as well as numerical or temporal data values. In this case the form author is defining which language of input they desire whereby dictionary and additional assistance can be given. By automatically applying a static application-level setting the user will always be given assistance in their own language which isn't very helpful in answering a question such as "what is your favourite colour?" for a different language. Even for non-native speakers with such auto-assistance even i might be able to enter a correct value in french or whatever other language was defined on the page\element. The notion that native periods or comma usage in data entry is too confusing to decipher fails to take into account they the user has already navigated to a foreign language page and is obviously already capable of interacting with it enough to decipher what the form they are entering data into means. Possibly the addition of a placeholder text would definitively communicate this to the user for these types. The case for CSS presentational specification of formatting is desirable in the case of date\time values which typically can take a large variety of formats and is distinct from their value. Unicode defines both enumerated FULL, LONG, MEDIUM, SHORT pre-configured settings and symbol format templates. Since these have no affect on the data values themselves the place seems to be CSS, however their interaction with data entry would in effect result in applying pattern restriction in order to retain parsing ability. For this reason i think this negates using CSS for this purpose in favour of possibly a format attribute or such. Thanks, Cameron Jones
