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

Re: font features in CSS

From: Thomas Phinney <tphinney@cal.berkeley.edu>
Date: Fri, 30 Oct 2009 13:09:08 -0700
Message-ID: <f49ae6ac0910301309o4453dc18n92fa3f3e06f3146a@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: Bert Bos <bert@w3.org>, www-font@w3.org, www-style@w3.org
On Fri, Oct 30, 2009 at 10:41 AM, fantasai
<fantasai.lists@inkedblade.net> wrote:
> Bert Bos wrote:
>>
>> Yes, we should choose names that match the style of the other keywords
>> in CSS. No need to copy the naming style of OpenType or other font
>> formats.
>>
>> Moreover, I don't think it is a requirement that CSS supports all OT
>> features. A handful of the more common ones is enough. If a designer
>> wants a specific feature of a specific font, he can make a new font (or
>> a virtual font) in which that feature is turned on. That's what we have
>>  @font-face for.
>>
>> We don't provide ways either to replace colors in a JPEG or change a
>> circle to a square in an SVG. The designer just makes a new image with a
>> new URL. That's a more flexible and modular solution.
>>
>> I think we should provide keywords for small caps (already done) and
>> oldstyle figures, and maybe one or two more. But if a font has half a
>> dozen different ampersands and the designer really wants the fourth
>> variant, he should make a font with that glyph. (Or maybe he actually
>> meant to use an image?)
>
> I agree with Bert's position here. For a lot of these less common features
> (and by common, I mean common to fonts, not just commonly used), the values
> and their appropriateness is very font-specific. That says to me that it
> should be in the @font-face rule. Triggering alternate glyph set #2 when you
> have no guarantee of what font ultimately gets used seems like a good way
> to introduce cross-platform problems.

Yes, the appropriateness is font-specific, but with @font-face we are
soon going to be fairly sure about what font we are getting, much of
the time (and with the font fallback stack we can be sure to specify
as fallback something that is unlikely to trigger an undesired result
for selecting alternate ampersand #27).

I don't think you necessarily want to put this sort of stuff right in
the @font-face declaration, however. You spec the font in a more
global way, and want to apply formatting much more locally. I don't
want to have to re-spec the font just to turn on swash caps or get a
fraction... seems unnecessary and undesirable.

Cheers,

T
Received on Friday, 30 October 2009 20:09:48 GMT

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