Re: [selectors-api] Selectors API I18N Review...

You appear to be mistaken. The definition of Unicode Normalization does not
depend on the platform.

Now, what you may mean is that the implementation of Unicode Normalization
on the Mac is different than on other programs. I would be quite surprised
to hear that (cc'ing also some Apple folks who would know).

Alternately, you could mean that the Mac uses different Unicode
Normalization than you expect, since there are 4 different forms of Unicode
Normalization (NFC, NFD, NFKC, NFKD). I believe that Apple is using NFD in
the file system internally, but don't know whether or how this is apparent
to users. The Mac also does support NFC, however, which is the preferred
form for interchange.

Mark


On Tue, Feb 10, 2009 at 12:11, Daniel Glazman <
daniel.glazman@disruptive-innovations.com> wrote:

>
> Richard Ishida wrote:
>
>> Hi Anne,
>>
>> No, this is a theoretical outcome if some browsers did start normalizing.
>>  I don't know of any that do at the moment - though I haven't exactly
>> scoured the whole list of UAs at this point.
>>
>
>
> Sorry to interrupt this discussion, I originally missed it because it
> ended up in my spam folder for some strange reason.
>
> I am using a Mac. On Mac, Unicode normalization gives me e' for
> &eacute; while most other systems will give me é.
>
> So if I start authoring on my Mac for instance a document and have
> to use a corporate stylesheet made on a PC, both instances using
> class "barré", do I take the risk of having my styles not applied ?
> If the answer is yes, it's unacceptable, even the input method or
> the OS is guilty. The user cannot have to worry about that and must
> be provided with a workable solution. A solution that chokes on acute
> e in french is not workable, even in the name of purity of the solution.
>
> </Daniel>
>
>
>

Received on Tuesday, 10 February 2009 20:53:42 UTC