RE: [css3-fonts] font-size-adjust auto issue

On Monday, August 26, 2013 10:56 PM Tab Atkins Jr. wrote:
> 
> On Mon, Aug 26, 2013 at 7:01 PM, Levantovsky, Vladimir
> <Vladimir.Levantovsky@monotype.com> wrote:
> > On Sunday, August 25, 2013 12:52 PM Tab Atkins wrote:
> >>
> >> Yes, it does mean that it'll be adjusted to match Times.  Whether
> >> this makes the font less legible is up to individual interpretation,
> >> I suppose.
> >
> > Not so. According to the spec "the relative height of lowercase
> letters compared to their uppercase counterparts is a determining
> factor of legibility". Adjusting a font with larger x-height to match
> the lower x-height will harm the legibility.
> 
> font-size-adjust doesn't change the relative heights.  It can't,
> without warping the glyphs.  So this seems irrelevant.
> 

While it doesn't change the relative height within a glyph, it does change the relative x-heights between various font - this is a stated goal and specified behavior. Depending on whether the lower x-height is adjusted to match the larger x-height or vice versa will have an effect on text readability and legibility (again, as stated in the spec) - it will either improve it or make it harder to read. I'd rather make sure that the authors know the results they are getting, which they can't with 'auto' value selected.

> >>
> >> Specs are indeed misleading if you regularly read only the first half
> >> of normative sentences.  The "defined for the initial value of the
> >> 'font-family' property" is a necessary part of that sentence which
> >> makes it clear what is meant - the "initial value" of a property is a
> >> term of art in CSS that is defined in the propdef tables.
> >>
> >
> > Agree, but there is also a second sentence there that says that
> "Effectively this is the default font used when ‘font-family’ is not
> otherwise specified." Since in my case (and also in Example 3) the
> font-family is specified, it "effectively" renders the second half of
> the normative sentence irrelevant, and the fact that Figure 19 also
> shows the result of the adjustment when every font in the font-family
> is adjusted to match the x-height of the first font Verdana visually
> reinforces the assumption that this is the expected behavior.
> 
> I don't understand the first part of this paragraph.  What effect can a
> correct non-normative elaboration have on a normative requirement?
> 

How did you deduce that in a two-sentence paragraph describing the 'auto' value the first sentence is normative and the second one is "a correct non-normative elaboration"? You may be right that if the language of the spec was machine-readable and properly parsed, having a strictly define algorithm applied we could come up with the formal conclusion that the language of the spec is correct, but it is meant to be read by humans, no?

> As for the second half, Figure 19 doesn't specify what value it's
> using.  It's merely illustrating the effects of a possible font-size-
> adjust use.  I'm not sure why you're apparently assuming it's
> incorrectly illustrating the effect of 'auto'.
> 

Yes, the example 3 and its description doesn’t provide any clue as to what is the value of the property used but the visual results show that adjustments are performed to match the x-height of the first font defined in the font-family list, which is consistent with the ambiguous definition of the 'auto' value. (I do realize that using "consistent" and "ambiguous" in the same sentence is an oxymoron ;-)

> >> The use-case for <auto> has been explained - it provides a useful
> >> number without the author having to take the time to measure things
> >> themselves, and there's a good chance that it matches the font
> >> currently being used, since most pages just uses the browser default
> >> fonts for most text.  The default font for the browser is presumably
> >> nicely legible, such that matching its x-height is acceptable.
> >
> > This "useful number" will vary from one platform to another, which
> makes its usability highly questionable, especially considering the
> very first sentence that says "For any given font size, the apparent
> size and legibility of text varies across fonts".
> 
> If the author knows the right value to use for their desired font, they
> should obviously use that anyway, regardless of whether or not 'auto'
> exists.
> 
> If they don't know and don't care to calculate it (it's somewhat
> annoying to do so - blow up the text size and break out your ruler?),
> without 'auto' they have to guess.
> 

And with 'auto' - they will never know (and will have to keep guessing) what the end results would be - hardly an improvement if you asked me. I'd rather have them to either know the right value and use it or not mess with it at all.

> >> Having all of your fonts match *some* reasonable x-height is useful
> >> all by itself; you don't need the ability to specify a specific
> >> x-height to make this functionality useful.
> >>
> >
> > Fonts are designed with different x-heights and varied proportions
> for a reason. And, as far as x-heights are concerned, what is
> reasonable for one typeface design may be not so for another. My
> objection to having <auto> value is because it encourages authors to
> use it blindly, not knowing (and having no chance to know precisely)
> what the effect will be on any given platform.
> 
> Yes, fonts are designed with varied x-heights for a reason.  And font-
> size-adjust helps when you don't care, because the desired effect is to
> have them all have the same x-height.
> 

I'd argue that "don't care - don't touch" is a sensible strategy when it comes to text legibility and readability. If one doesn’t know and doesn’t care - let type designers (who designed fonts for authors to use) be concerned about legibility. It's bad enough if misinformed authors make wrong font choices, it's even worse if they attempt to make adjustments having no clue what the results will be. Achieving the same x-height among different fonts is *not* the stated goal for the 'font-size-adjust' property - text readability is the primary concern here!

Cheers,
Vlad

Received on Tuesday, 27 August 2013 15:47:06 UTC