- 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