W3C home > Mailing lists > Public > www-style@w3.org > January 2015

CSS Localization

From: Cameron Jones <cmhjones@gmail.com>
Date: Thu, 8 Jan 2015 15:03:14 +0000
Message-ID: <CALGrges2ZCTEaQB-f4eBkqKkexNtJ2-EQOeV=_m0oaeiPD0EHA@mail.gmail.com>
To: www-style@w3.org
Hello www-style,

I'm following up on discussions across html and i18n wgs regarding
localization of form controls and other locale-specific data:


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

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

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:

time zone data
collation order
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

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


Cameron Jones
Received on Thursday, 8 January 2015 15:03:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:50 UTC