The unicodeEquivalentType parameter provides four possible parameters. Three of these (canonical, compatibility, and all) allow either C or D forms rather than specifying which shall be used. Because of the nature of what FindText is doing (finding matching code point sequences), the results may vary depending on which normalization form is chosen. The FindText API should either (a) be specific about whether the composed or decomposed sequence is used or (b) define separate terms for composed and decomposed (that is, provide four Unicode normalizations: NFC, NFD, NFKC, and NFKD).
http://www.w3.org/International/track/issues/501 [I18N-ISSUE-501]
http://www.w3.org/TR/2015/WD-findtext-20151015/#idl-def-UnicodeEquivalenceType.canonical
The unicodeEquivalentType parameter provides four possible parameters. Three of these (canonical, compatibility, and all) allow either C or D forms rather than specifying which shall be used. Because of the nature of what FindText is doing (finding matching code point sequences), the results may vary depending on which normalization form is chosen. The FindText API should either (a) be specific about whether the composed or decomposed sequence is used or (b) define separate terms for composed and decomposed (that is, provide four Unicode normalizations: NFC, NFD, NFKC, and NFKD).