(found in bug 465034 comment 5, test case: http://tenten-taiko.com/font-face-test.html) test case (fails): http://dev.l-c-n.com/css3/font-face/order-of-rules1.html test case (works) http://dev.l-c-n.com/css3/font-face/order-of-rules2.html When specifying an @font-face rule to specify a ttf file, followed by a rule specifying a EOT file, Gecko fails to download/use the ttf file. This fails: @font-face { font-family: "square"; src: url(./fonts/Ahem.ttf) format("truetype"); } @font-face { font-family: "square"; src: url(./fonts/fontAhem.eot); } But this works: @font-face { font-family: "square"; src: url(./fonts/fontAhem.eot); } @font-face { font-family: "square"; src: url(./fonts/Ahem.ttf) format("truetype"); } (the fontAhem.eot does not exist on the server, but that doesn't affect the issue)

So I think the order of the @font-face rules has to affect something, but we should do fallback across them; I filed bug 465414 for that earlier today.

This is a limitation of our current implementation, related to our not supporting unicode-range. For a given style point (i.e. font descriptor settings) there can only be one font, in this case weight normal, style normal, stretch normal. Once unicode-range is supported we can support multiple faces per style point. The fallback order will still depend on order in which rules are specified.

All testcases are no more available.

The testcases are gone, but AFAIK this should no longer be an issue since we implemented unicode-range and related changes to @font-face handling. Resolving as WFM; please re-open if it is not in fact fixed (in which case an updated testcase would be good).