W3C home > Mailing lists > Public > www-style@w3.org > February 2012

non-support of using surrogate pairs in CSS escapes [I18N-ACTION-90] [I18N-ISSUE-147]

From: Phillips, Addison <addison@lab126.com>
Date: Tue, 31 Jan 2012 21:00:06 -0800
To: "CSS WWW Style (www-style@w3.org)" <www-style@w3.org>
CC: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Message-ID: <131F80DEA635F044946897AFDA9AC3476AA738994D@EX-SEA31-D.ant.amazon.com>
Dear CSS WG,

I am writing to you on behalf of the I18N Core WG. During a recent teleconference [1] I was actioned with responding to a recent thread on your mailing list [2]. 

Here's a quote of much of that email:
WebKit browsers don’t support this syntax for characters outside the
BMP: https://bugs.webkit.org/show_bug.cgi?id=76152 ...

There seems to be another way to escape these characters, namely by
breaking them up in UTF-16 code units: `\d834\df06 `. All browsers
except Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=717529)
seem to support this, even though this isn’t mentioned in the spec.

Should the spec be changed to reflect reality?

The Internationalization Core WG strongly opposes making such a change to the CSS spec. The Character Model [3] in requirement C045 requires that escape sequences be related to Unicode code point values, not to the code unit values used in some specific Unicode encoding (such as UTF-16). It is a barrier to content authors to have to convert escapes into UTF-16 surrogate pair sequences: it obfuscates the stylesheet, introduces additional processing complexity, and adds no value to support this syntax. Instead, user-agents should be encouraged to better meet the specification.

Regards (for I18N),


[1] http://www.w3.org/2012/01/25-i18n-minutes.html#item05

[2] http://lists.w3.org/Archives/Public/www-style/2012Jan/0536.html 
[3] http://www.w3.org/TR/charmod/#sec-Escaping 

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Received on Wednesday, 1 February 2012 05:00:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:15 UTC