W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: [css3-fonts] alternative to font-size-adjust:auto [was Re: Agenda conf call 21-aug-2013]

From: Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com>
Date: Sat, 24 Aug 2013 17:12:26 +0000
To: John Daggett <jdaggett@mozilla.com>
CC: Jonathan Kew <jfkthame@googlemail.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <FDBE7B75-7F30-42D3-9493-E4814F0482B3@monotype.com>
Hi all,

Thank you for your replies and the detailed comments. Based on the specific details presented during this email discussion I am still not convinced that <auto> value is useful and practical. It seemed that, to the contrary, in most of the cases the rendering results will be different on different platforms, and that the applied adjustments will most likely adversely affect the text legibility.

My initial suggestion to have only two possible values defined (<none> and <number>, with <none> being the default) seems to be a good alternative option (and a simple fix):
- no harm done if nothing is specified,
- authors who know what they are doing will define a specific number based on their 'first choice' font,
- consistent results on different platforms,

I also believe that the scaling behavior needs to be described in the spec. In particular, it needs to clarify that while font size may be adjusted to specified aspect value, the line spacing of text needs to be calculated based on the declared font-size and that in some cases the results of the font-size-adjust may cause either a collision between ascenders and descenders or clipping (e.g. when a font with very small original aspect value is adjusted to specified, larger value of font-size-adjust property

Thank you,
Vlad


On Aug 21, 2013, at 11:16 PM, "John Daggett" <jdaggett@mozilla.com> wrote:

> 
> Jonathan Kew wrote:
> 
>>> The LC period for Fonts runs through tomorrow.  Right now there's
>>> an open issue regarding 'font-size-adjust: auto' that I think needs
>>> to be addressed before we can move to CR.  I'm hoping we can wrap
>>> this issue up this week which will allow us to resolve to move to
>>> CR on next week's call.
>> 
>> It seems to me from the recent thread here that the biggest problem
>> with font-size-adjust:auto is that people are misunderstanding what
>> it means. Even experienced spec-readers here seem to easily misread
>> 
>> # Behaves just like <number>, except the number used is the aspect
>> # value calculated by user agents for the first font in the list of
>> # fonts defined for the initial value of the ‘font-family’ property.
>> 
>> as though it said
>> 
>> # Behaves just like <number>, except the number used is the aspect
>> # value calculated by user agents for the first font in the list of
>> # fonts in the ‘font-family’ property.
>> 
>> (and then start to wonder what happens if that "first font" isn't
>> available, etc.) Not sure how to make that clearer, but I think
>> we've seen ample evidence that the current text is not communicating
>> adequately.
> 
> I agree, it seems to me most of the problem here is confusion over the
> precise nature of the intended behavior.  I think the spec is clear but
> it would definitely benefit from a note explaining why the "initial value
> of 'font-family'" is not equivalent to the first font in the font list.
> 
>> In addition, there's the question of whether "auto" is a good name
>> for this behavior.
> 
> I think the goal of this value is simply to fix the aspect value to a
> constant value.  This allows an author to lay out text on a page
> knowing that the user will see text with roughly the same x-height
> independent of fonts available.  So I think "auto" is perfectly
> reasonable here.
> 
>> Here's a thought: suppose that instead of "auto", you could say
>> 
>>   font-size-adjust: <generic-family>;
>> 
>> to specify that the UA uses its calculated aspect value for the font
>> that corresponds to the given CSS generic. So typical usage might be
>> 
>>   font-family: Gentium, Times, Georgia, Liberation Serif, serif;
>>   font-size-adjust: serif;
>> 
>> would match whichever of the serif fonts is used to the browser's
>> default serif face...
> 
> So the idea is that there are different values for each generic type?
> I'm not sure this behavior would be any better than the functionality
> of the existing 'auto' value.  I think it would be harder for authors
> to understand; where 'auto' to some extent implies that the user agent
> is trying to use good default behavior, using generics means the
> author would need to understand the difference between
> 'font-size-adjust: serif' and 'font-size-adjust: sans-serif'.
> I'm not sure I see an easy rule of thumb way of deciding that.
> 
> I think we still need to hear from Vlad about this issue but at this point 
> I guess I see several different options:
> 
> 1) 'auto' is fine as defined but explain clearly that it doesn't imply the
>   use of the aspect value of the first font in the font list
> 
> 2) switch to using generics, instead of 'auto', have 'serif', 'sans-serif', etc.
> 
> 3) drop the value altogther and suggest the use of an arbitrary value (e.g. 0.5)
> 
> The one advantage of (3) is that it allows authors to know absolutely
> that text will *always* have the same x-height as what they see in
> their design environment.  Even if the fonts are different on other
> platforms, the font size will always be scaled so that the x-height of
> the font used matches that of the font used by the author in their
> design environment.  The use of 'auto' or generics suffers from the
> problem that different user agents may have different default fonts
> with varying aspect values.
> 
> Regards,
> 
> John Daggett
> 
Received on Saturday, 24 August 2013 17:12:52 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 24 August 2013 17:12:52 UTC