W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: Proposal: add a "small-caps" value to "font-synthesis"

From: Alan Stearns <stearns@adobe.com>
Date: Thu, 30 Jul 2015 23:41:02 +0000
To: "Myles C. Maxfield" <mmaxfield@apple.com>
CC: www-style list <www-style@w3.org>, Ted O'Connor <eoconnor@apple.com>
Message-ID: <B106120B-C4D7-4052-838A-6C742CDB4EC2@adobe.com>
On 7/30/15, 4:32 PM, "Myles C. Maxfield" <mmaxfield@apple.com> wrote:

>> On Jul 30, 2015, at 3:00 PM, Alan Stearns <stearns@adobe.com> wrote:
>> 
>> On 7/30/15, 2:42 PM, "Myles C. Maxfield" <mmaxfield@apple.com> wrote:
>> 
>>> Hello,
>>> 
>>> The font-synthesis CSS property is a way for authors to opt-out of 
>>> synthesized font traits such as bold or italics. It seems reasonable 
>>>to 
>>> add small-caps to this set. Using "font-synthesis: small-caps;" would 
>>> specify that, if a small-caps font cannot be found, to use a 
>>> non-small-caps font without synthesizing smaller, capital, text.
>>> 
>>> What are your thoughts?
>> 
>> I like the idea of disallowing shrunken small caps, but font-synthesis 
>> appears to be specified in the reverse of your usage: 
>> “font-synthesis:weight;” allows smearing and “font-synthesis:none;” is 
>>the 
>> setting to disallow it. That makes it difficult to add new categories 
>>of 
>> synthesis blocking using that property.
>> 
>> Thanks,
>> 
>> Alan
>
>Whoops! You are right.
>
>Please consider the amended proposal of adding the new CSS value, and 
>adding this new value to the initial value of font-synthesis.
>
>You are correct about the compat risk. It seems that the original 
>property probably should have been created to mean the inverse of what it 
>means today. Alas, i've misplaced my time machine.
>
>Given that font-synthesis is rarely used (and small-caps is also rarely 
>used), do you have opinions regarding adding this new value anyway?
>

I’d be in favor of adding the value, since I agree the compat risk is 
small. And I'd like a way to turn off shrunken small caps.

But since we’re changing the initial value anyway, what about changing it 
to ‘all’? Then we could add new values without changing the initial value, 
and limit future compat risk to new behavior for the ‘none’ value.

Thanks,

Alan
Received on Thursday, 30 July 2015 23:41:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC