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

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

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 2 Feb 2009 12:35:08 -0800
To: "Phillips, Addison" <addison@amazon.com>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <20090202203508.GB25721@pickering.dbaron.org>

On Monday 2009-02-02 11:00 -0800, Phillips, Addison wrote:
> If you make selectors require normalization form NFC, you can
> normalize the elements when atomizing them in the first place. For
> certain things, you might need to store both normalized and
> "original" representations.

We can only normalize the element names and attribute names if
everything else that uses them also accepts that they're normalized.
I'd really like this to be the case, and then just do
post-encoding-conversion normalization.  But I've interpreted a
bunch of arguments made against what I said as saying it would be
unacceptable to do this.

> If selectors require NFC internally, you can safely normalize
> during the initial processing. That's part of the point of
> recommending NFC in the first place. You might still store the
> original code point sequence for rendering purposes (although that
> should be for non-markup content).

The issue is that we're matching the selectors against the content
(DOM tree), and we'd want both the selectors and the content they're
matching to have all their data normalized already.


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Monday, 2 February 2009 20:35:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC