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

Re: [css3-fonts] new editor's draft

From: Michael Day <mikeday@yeslogic.com>
Date: Wed, 21 Jan 2009 22:19:56 +1100
Message-ID: <497704DC.70409@yeslogic.com>
To: John Daggett <jdaggett@mozilla.com>
CC: www-style <www-style@w3.org>

Hi John,

> Defined this way, authors have the ability to control load behavior (example 1) and to control fallback behavior (example 2).

Would it be possible to do this in another way? The chosen solution 
appears quite non-obvious. Consider this example:

@font-face {
     font-family: MyFont;
     src: local("Arial"), local("Verdana")

@font-face {
     font-family: MyFont;
     src: local("Helvetica"), local("Gill Sans")

p { font-family: MyFont }

Thinking about the combination of which fonts are present and what 
impact that has on the rendering of the text in the paragraph with glyph 
fallback makes my head hurt, and the syntax doesn't give any hint that 
the second @font-face rule augments the first in a subtly different way 
to concatenating the two src properties.

In Prince we have used the opposite solution for the past six years, 
where each font in the src property is tried in turn, and there is only 
one kind of font fallback. That may sound more limited in theory, but 
our users find it convenient and there has not been demand for a more 
complex font fallback scheme.

While it is possible to concoct scenarios involving combinations of 
local fonts, downloaded fonts, different unicode-ranges and subtle 
fallback behaviour to result in a perfect appearance, I wonder how 
common these will actually be. Some considerations:

  - Complex fallback behaviour could be implemented using an additional 
property or keyword value, to make it clear exactly what is being asked 
for, and not snuck in in such a subtle way.

  - A website that presents unusual combinations of multilingual text 
and needs to ensure that the right combination of fonts are used could 
use downloadable web fonts, and eschew the complicated interplay of 
local and remote fonts entirely. Since there is no way to select a local 
font by its version or codepoint coverage this seems a lot more practical.

  - Are these feature requests coming from experience with actual use of 
@font-face rules, or ideas about how the feature might be used by some 
imagined website that doesn't exist?

Overall, I think that for a feature that has sat on the back burner for 
so long, it would be a shame to rush to make it overcomplicated based on 
requirements that may not really be necessary.

Best regards,


Print XML with Prince!
Received on Wednesday, 21 January 2009 11:20:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC