(In reply to comment #0)
> Mozilla is going to implement cluster-based font matching. The spec should be
> updated accordingly.

The right way to term this is that the CSS3 Fonts spec needs to clearly define font fallback behavior for character clusters, so that user agents can implement this in a consistent way.

There are several relevant issues here:

- exact definition of a "cluster" in this case
- priority of base + combining character vs. precomposed characters
- role of normalization and specifying this in a way that does *not* normalize characters like CJK compatibility ideographs.

One additional issue, how exactly to do font matching of clusters involving IVS sequences.  This is similar but slightly different from the base + combining character vs. precomposed character issue, so I think it will require explicit handling instructions.

In terms of normalization, the more I look at this I think we probably need to use only the "Canonical Composition Algorithm", defined within the definition of Unicode normalization forms.  

Using NFC means that as part of the canonical decomposition ==> canonical composition, there are many singleton codepoints which will be transformed (CJK Compatibility codepoints, symbols like Angstrom and Kelvin, etc.) and "lost" as part of the recomposition.

Using only the composition step allows authors to control precisely the rendering of characters via the combination of codepoints + font, something the usage of NFC does not permit.

Resolved by the addition of explicit rules for font matching of clusters.

http://dev.w3.org/csswg/css3-fonts/#cluster-matching