W3C home > Mailing lists > Public > www-style@w3.org > January 2010

re: Conformance criteria for the src descriptor in CSS Module Level 3 - seeking clarification

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 4 Jan 2010 22:39:03 -0800 (PST)
To: www-style <www-style@w3.org>
Message-ID: <92691394.54845.1262673543042.JavaMail.root@cm-mail03.mozilla.org>

Richard Fink posted a question on the @font-face rule to the www-font list:
http://lists.w3.org/Archives/Public/www-font/2010JanMar/0000.html

> I’ve been writing some test pages (part of an article on @font-face
> syntax I’ve been asked to write) and I’m finding the draft a bit
> ambiguous regarding the src descriptor. Specifically, the question is
> whether multiple src descriptors within a @font-face declaration would
> or should validate as conformant.
> 
> http://www.w3.org/TR/css3-fonts/#the-font-face-rule
> 
> It says:
> 
> “When a given descriptor occurs multiple times in a given @font-face
> rule, only the last specified value is used, all prior values for that
> descriptor are ignored.”
> 
> This would suggest that it’s OK to have more than one src descriptor
> appear textually, but that all but the final one are ignored.
> 
> In other words, this:
> 
> @font-face{
>   font-family: ‘some font’;
>   src: url(somefont.otf) format(‘opentype’);
>   src: url(somefont.ttf) format(‘truetype’);
> }
> 
> Is the functional equivalent of this:
> 
> @font-face{
>   font-family: ‘some font’;
>   /* src: url(somefont.otf)format(‘opentype’); */
>   src: url(somefont.ttf) format(‘truetype’);
> }

These are functionally equivalent but a validator would probably flag
the first one (multiple src descriptors) and not the second one.  The
defined behavior of a parser is to ignore all but the last descriptor
definition.

> So, I suppose my question can be phrased this way: if you were writing a
> validator, would more than one src descriptor within a @font-face rule
> be flagged as non-conformant? Or what?

Yes but the error handling behavior should work as described.  This is
not XML (thankfully).

> FYI – in a test of this – where the second src descriptor is crafted to
> be unrecognizable by the user agent and the @font-face declaration
> should therefore fail and no font resource downloaded or applied - IE,
> FF, Chrome, and Safari all pass. Opera fails.
> 
> The test declarations being:
> 
> @font-face {
>   font-family: 'testfont';
>   src: url('dustismo_roman.ttf') format('truetype');
>   src: url('dustismo.nnf') format('nofont'); /* constructed to fail */
>   font-weight:normal;
> }
> 
> And for IE:
> 
> @font-face {
>   font-family: 'testfont';
>   src: url('dustismo_roman.eot');
>   src: url('dustismo.nnf') format('nnf');
>   font-weight:normal;
> }
> 
> All but Opera ignore the declaration and display the fallback font – as
> they should IMHO. However, Opera breaks with the pack and takes what it
> can get successfully, despite the draft standard, and displays Dustismo
> Roman.

This rule will parse but you're correct, no font should be downloaded
since under no circumstance should a user agent download the data for a
format it doesn't understand.  The fallback font should be used instead.

IE doesn't currently understand src descriptor format hints and the
whole reason for using multiple src descriptors is to deal with how IE
implemented @font-face historically, eventually the need for hacks like
this will fade.  

Cheers,

John Daggett
Mozilla Japan
Received on Tuesday, 5 January 2010 06:39:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:23 GMT