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

Re: font-specific feature handling

From: Christopher Slye <cslye@adobe.com>
Date: Thu, 18 Mar 2010 18:00:25 -0700
Message-ID: <6BB0D686-4C05-4E0A-B48B-85CD45BE22C5@adobe.com>
To: www-style <www-style@w3.org>

On Mar 18, 2010, at 5:19 PM, Tab Atkins Jr. wrote:

> On Thu, Mar 18, 2010 at 4:04 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> Another approach, which I raised the previous time we discussed this, is to
>> allow font-specific features (i.e., numbered features) everywhere, but
>> (outside @font-face) we only apply those features where the font being used
>> to render the text is the first font in the font-family property.
> 
> That's probably the easiest, though it's kind of weird.

I agree -- easy, and slightly weird. But what if you really did want to apply it to a fallback font? Inevitably, we'll have "new" versions of OpenType fonts, where the font name will be different (e.g. new "WarnockSuperFab" vs old "WarnockPro") but they will both have compatible features. And what if the first font is a local font that falls back to the same font on the web? Better to use the big font on a user's system rather than downloading it, right? I guess it would be back to specifying it in @font-face, then.


> 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.

-Christopher
Received on Friday, 19 March 2010 02:01:39 GMT

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