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

[css3-fonts] font resource error handling

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 18 Feb 2013 20:37:59 -0800 (PST)
To: www-style list <www-style@w3.org>
Message-ID: <1604664265.3385669.1361248679133.JavaMail.root@mozilla.com>

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
Received on Tuesday, 19 February 2013 04:38:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT