- From: Cameron Jones <cmhjones@gmail.com>
- Date: Thu, 8 Jan 2015 15:03:14 +0000
- To: www-style@w3.org
- Message-ID: <CALGrges2ZCTEaQB-f4eBkqKkexNtJ2-EQOeV=_m0oaeiPD0EHA@mail.gmail.com>
Hello www-style, I'm following up on discussions across html and i18n wgs regarding localization of form controls and other locale-specific data: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859 I'd invite you to read through the discussion but i'll also summarize what was derived and try to provide some suggestions for what could be a localization module for CSS. --------------- There is new functionality added within HTML5 which is inherently international and requires localization for display to the user. These include the new form controls (eg: date, number, etc) and other data elements, ie <time> and potentially <data> too. HTML includes a global "lang" attribute for defining the locale of an element using BCP-47 codes, and a method for deriving the applicable locale based on an element's parent, meta extension, http header or platform locale. The implementation of localization within browsers uses the platform locale for any localization of pages. This leaves no potential for configuring localization either to enable a locale override or to enable multilingual documents to exist. It is believed that the place to define the functionality for configuring the render locale and any further localization customizations (ie format skeletons) should be provided through CSS as a matter of separation of style from content. As such, it is believed that no further changes to HTML are necessary and that in order to support the functionality added to HTML5 there is the need for additional functionality within CSS. Locale Property --------------- The functionality required to be defined, at minimum, is the ability for an author to control the effective locale used for render. This could be provided by adding a new "locale" property: * { locale: <user-locale | page-locale | no-locale | BCP-47 | inherit | initial | unset> } The "user-locale" setting is the current default and would resolve the locale from the platform. The "page-locale" setting would use the HTML language resolution algorithm to resolve the locale. The "no-locale" setting would allow the raw machine-readable data to be directly rendered as text. The "BCP-47" option would allow the author to define any locale directly as a CSS value. Format Property --------------- There is no universal format for defining format skeletons so this will no doubt induce the need for one to be specified within and for CSS. BCP-47 as a means of defining locale uses the CLDR for providing localization data. The CLDR specifies format syntax which may be a good starting point and as a means to reuse as many existing conventions as possible. In addition to custom format skeletons, it is also common for dates to provide format enumerations: SHORT, MEDIUM, LONG. This implies there could be both a method for configuring which format an element should use for presentation, and a method for configuring the specific format skeletons. It is also worth noting that operating systems usually provide a means for customizing format configuration. As such, integrating with these platform functions would be desirable for users. :locale Selector ---------------- The existing localization support in CSS can be regarded as the :lang selector. This selector uses the HTML "language resolution algorithm" to return the applicable BCP-47 locale for the content. As the default render locale is defined by platform, in order for styles to be targeted to specific effective locales this may require introducing a new :locale selector which reflects the CSS "locale resolution algorithm" as defined by the locale property. BCP-47 Extensions ----------------- As BCP-47 is the base for localization configuration it is worth noting that the "Extension Subtags" could be useful as an additional source of configuration. These subtags include the following: calendar time zone data collation order currency number system For example, the use of "calendar" and "time zone" extensions could be used to configure date/time form inputs for specificity. There is currently no ability to define these properties over data values which is a limitation that these extensions could satisfy. ----------------- Is there interest within the group to work on defining localization within CSS? As CSS is modular in structure, and as localization is largely independent from other CSS features, it seems to me that this might make sense as a new module? Thoughts? Thanks, Cameron Jones
Received on Thursday, 8 January 2015 15:03:44 UTC