Unicode normalisation form C and Apple Safari

Question

Technically, the World Wide Web Consortium specifies normalisation form C. This suggests that Apple Safari 3.2.1 should not establish equivalences (aliases, synonyms) to other coded characters if a coded character has no specified equivalences as per normalisation form C. Nonetheless, Apple Safari 3.2.1 does seem to establish equivalences.
Anyone have any thoughts?
/hh
Reference:
http://unicode.org/faq/normalization.html#6

Answer 1

According to Asmus Freytag, the character LATIN SMALL LETTER LONG S was encoded because it involves a semantic distinction as opposed to a stylistic distinction in that writing system
It does have a compatibilty decomposition to "s" , however.
If the World Wide Web Consortium specifies Form C, if no equivalences are established for LATIN SMALL LETTER LONG S under Form C, and if HTML is opened from disk in a browser, then LATIN SMALL LETTER S should not be successful as a synonym in a search string, it seems. Thus, Faust should not successfully retrieve Fauſt
I guess that would be correct under String Identity Matching as defined here?
http://www.w3.org/TR/charmod-norm/#sec-IdentityMatching
It seems true that Edit > Find uses a less restrictive matching system, but it's not clear to me that doing that is contrary to the standards in some way.
It's not just Safari but all apps where you can find ſ by looking for s, right?
and the Related Characters pane in the Character Palette should not show that LATIN SMALL LETTER S and LATIN SMALL LETTER LONG S are unconditional synonyms. Rather, they are conditional synonyms.
I'm somewhat mystified as to exactly what the Related Charcters pane is supposed to show, other than characters that look similar. I wonder how Apple chooses them? In any case I would hope the compatiblity decomposition of a character would appear there.
It seems to me that search services can compete by seeming to be more successful, and to seem more successful search services can establish equivalences which are broader than the equivalences that an author is entitled to expect based on specifications and standards.
I think the w3c standards about this are mainly related to the form a text should have on the web, rather than what results search services should return (unless the services perhaps specify they are doing a "string identity match").