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: Tue, 27 Aug 2013 14:49:16 +0000
To: John Daggett <jdaggett@mozilla.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <79E5B05BFEBAF5418BCB714B43F4419923EBD568@wob-mail-01>
On Monday, August 26, 2013 2:12 AM John Daggett wrote:
> Vladimir Levantovsky wrote:
> > 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.
> Yes, the size will be different but the x-height of the used font will
> always match the x-height of the local default font.  That's what Tab
> was emphasizing. Authors who want the x-height to remain constant
> across platforms can use a generic, fixed value (e.g. 0.5).

I believe the primary stated purpose for 'font-size-adjust' property is maintaining text legibility. Matching x-height of a known legible font to an unknown local default font would indeed keep x-height constant but I am not sure this is a good thing if the result is a less readable text.

> > 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,
> Ok, so you feel the 'auto' value should be dropped.

I think that dropping the 'auto' value would be the easy and sensible fix - no harm done. The authors who do want to use the property would have to consciously choose the value of adjustment, knowing exactly the x-height of a font they want to match and, most importantly, achieving very deterministic results on any platform.

> > 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
> The 'font-size' and 'line-height' properties control font size and
> leading in CSS.  They are not directly linked but authors can use font-
> relative units [1] to make the line-height a function of the
> font-size:
>   font-size:   200%;
>   line-height: 1.2em;  /* == computed font size x 1.2 */
> Back in June the WG discussed whether the 'em' unit should be tied to
> the computed value *after* 'font-size-adjust' is applied. The
> conclusion of that discussion was that it should not for the 'em'
> unit. 

I agree and think that you made the right decision.

> The behavior you're asking for would be done in CSS via the 'em'
> unit, so I think you're basically making the argument that the 'em'
> *should* follow the effective font size after 'font-size-adjust'
> adjustments have been applied. I think your concern is that if 'font-
> size-adjust' doesn't affect the 'em' unit value used for 'line-height',
> then collisions may potentially occur.

No, I am not arguing for changing the way how 'em' unit value is calculated. Considering that the stated goal of 'font-size-adjust' is maintaining a relative height of the lowercase characters to improve legibility - this adjustment should not change the line spacing. I was simply saying that the details of the scaling behavior and the relationships between font-size, font-size-adjust and line-height (everything that we just discussed) aren't stated in the spec (or it may be mentioned elsewhere but referenced in the CSS3 Font Module) - I think it should be.

> I think in general the variations across platforms are relatively minor
> (+/- 10%) so I'm not convinced that collisions would result in
> practice.  But I do realize it's possible, especially if the author is
> keeping the leading very tight.

The results really depend on the choice of fonts. For example, the aspect value of many cursive fonts would be much smaller than generic body fonts and, if used together (e.g. for emphasis) the resulting adjustment is likely to cause uppercase character or ascenders of a cursive font collide with the body text. Or worse, the rendering system on some platforms may simply clip them to prevent collisions.

> I guess I'd like to know if you think this can be handled by a note in
> the spec or whether you think the defined behavior needs to be changed,
> for example by adjusting the 'em' size based on 'font-size-adjust'.

I am not arguing for the existing behavior to change but I do want to see it defined somewhere - both for implementers and for authors. Adding an informative note for authors would be fine but I think that the definition of the relationship between font-size, font-size-adjust and line-height should be normative.

Thank you,

> Regards,
> John Daggett
> [1] http://www.w3.org/TR/css3-values/#font-relative-lengths

> [2] http://lists.w3.org/Archives/Public/www-style/2013Jul/0092.html

Received on Tuesday, 27 August 2013 14:49:41 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:31 UTC