- From: Michael Day <mikeday@yeslogic.com>
- Date: Wed, 21 Jan 2009 22:19:56 +1100
- 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,
Michael
--
Print XML with Prince!
http://www.princexml.com
Received on Wednesday, 21 January 2009 11:20:44 UTC