W3C home > Mailing lists > Public > www-style@w3.org > February 2013

RE: [css3-fonts] font resource error handling

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>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178291BF9827E@TK5EX14MBXC223.redmond.corp.microsoft.com>
[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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:09 UTC