- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Fri, 22 Feb 2013 18:44:34 +0000
- To: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
[John Daggett:] > Sylvain and Sergey from Microsoft pointed out an issue in the CSS3 Fonts > spec related to the error handling associated with @font-face rules. > Section 5.2 of the current draft [1], entitled "Matching font styles", has > the following description of how font resource load errors are handled: > > If a font family defined via @font-face rules contains only > invalid font data, it should be considered as if a font was > present but contained an empty character map; matching a > platform font with the same name must not occur in this case. > > This means that if the font resource associated with a given @font-face > rule is unavailable or invalid, when the font matching algorithm is run > the face with invalid font data will contain a null cmap and fallback will > occur. Firefox follows the spec but IE10 and Webkit implement slightly > different behavior, they ignore the face and match a different face within > the family. This seems like more intuitive behavior. > > Here's a testcase that illustrates this: > > http://people.mozilla.org/~jdaggett/tests/stylematching-invaliddata.html > > Webkit does the same as IE10 except if all faces are invalid, it will > ignore the @font-face family and match an underlying platform font family > if one exists with the same name. This isn't good, an author-defined > family shouldn't be accidently associated with a platform font family like > this. > > I think the IE10 behavior is better and we should adjust the font matching > algorithm to match that implementation. > > In place of the wording above, I propose the following replacement: > > If the font resources defined for a given face in an @font-face > rule are either not available or contain invalid font data, > then the face should be treated as not present in the family. > If no faces are present for a family defined via @font-face > rules, the family should be treated as missing; matching a > platform font with the same name must not occur in this case. > > With this change the spec will match IE10 behavior (and for the most part, > Webkit behavior also). > > Regards, > > John Daggett > > [1] http://dev.w3.org/csswg/css3-fonts/#font-style-matching We are happy with John's new wording. (Surprise, I know)
Received on Friday, 22 February 2013 18:45:47 UTC