W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2009

[CSS21][css3-namespace][css3-page][css3-selectors][css3-content] Unicode Normalization

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 29 Jan 2009 13:27:50 -0800
Message-ID: <49821F56.7010207@inkedblade.net>
To: Richard Ishida <ishida@w3.org>
CC: "'Phillips, Addison'" <addison@amazon.com>, public-i18n-core@w3.org, 'Lachlan Hunt' <lachlan.hunt@lachy.id.au>, www-style@w3.org

Richard Ishida wrote:
> Following on from our discussion at yesterday's telecon, I did some research into
> whether major browsers actually do normalise selector and class names for matching.
> The answer is that they don't.  
> Tests: http://www.w3.org/International/tests/css/tests-selectors/
> Results: http://www.w3.org/International/tests/css/tests-selectors/results-normalization
> (Thanks to Andrew for suggesting the use of Vietnamese.)
> I suggest we follow up on Elika's helpful note and request that the CSS WG
> re-examine this for CSS 2.1 and the CSS3 modules.  I think it is quite an
> important lapse, and I'm not sure how we missed it for so long.  Certainly
> this can cause major headaches for people working in Vietnamese and the
> many other languages that use combining characters, in that the cause of
> the failure to match names is not at all obvious, and fixing it may not be
> simple, especially if different people are working on the CSS and the markup.

Thanks for the tests and the report, Richard. Going from that, I think it
makes sense to require /not/ Unicode-normalizing CSS. It may be a bit
confusing indeed for people working in Vietnamese and other such languages,
but on the other hand behavior across browsers is interoperable right now.
If one browser started normalizing, then someone testing in that browser
would not notice that the page is broken in other UAs.

Received on Thursday, 29 January 2009 21:28:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:23:04 UTC