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

Re: font-specific feature handling

From: John Daggett <jdaggett@mozilla.com>
Date: Fri, 19 Mar 2010 00:49:21 -0700 (PDT)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style <www-style@w3.org>, Christopher Slye <cslye@adobe.com>
Message-ID: <840159078.25831.1268984961043.JavaMail.root@cm-mail03.mozilla.org>
Tab Atkins Jr. wrote:

>>> Otherwise, fantasai's alt-set idea seems like an interesting solution
>>> to Daggett's objections.
>> As much as I agree with John's aversion to code clutter, I do think
>> that it's better to keep these things tied to specific fonts, one way
>> or another. That said, I don't think John's solution would be the end
>> of the world. We already have this problem in desktop apps like
>> InDesign, which preserve these kinds of font-specific substitutions. I
>> don't think it's had a big real-world impact yet. Maybe someday it
>> will.
> Still a fundamentally different set of problems, though.  If InDesign
> preserves the substitutions, it's merely an annoyance when you notice
> that the new font you're using has weird substitutions.  In CSS, the
> weird substitutions will often/nearly always occur in a fallback font
> that the author *never sees*, and thus won't have an immediate clue that
> there's a problem.

Are you thinking of fallback within a given font list or in the system
fallback case?  What are the "weird substitutions" here, the use of a
different font or the use of strange variants?

Put another way, in the example below is the "weird substitution" the use
of fontB?  Or the use of a font chosen by the user-agent when all three 
fonts in the font list aren't available or don't contain a given character?

body { font-family: fontA, fontB, fontC; }


Received on Friday, 19 March 2010 07:49:54 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:44 UTC