Re: font-size-adjust in CSS3 Fonts module

On Tuesday 2011-05-03 07:56 +0000, Peter Constable wrote:
> -          It is Latin-centric, and not readily applicable to most scripts.

It's more than just Latin -- there are a number of other bicameral
scripts, including Cyrillic and Greek.

It it intended to be used only where appropriate, i.e., with
documents in bicameral scripts.

> Even for Latin text, I think the design of the property is problematic. The idea of matching x-heights is conceptually simple and at first glance seems a reasonable approach to get a good size match. But using the property requires the Web developer to figure out a specific ratio of two particular values in a font, neither of which is directly available to a Web developer: the x-height divided by the font units per em. Because the specific data isn’t readily available, the documentation describes a trial-and-error heuristic approach to understand the values for a given font: formatting two spans of text and tweaking the font-size-adjust value on one of the spans until they match. It’s awkward enough to lead people to start publishing tables for known fonts—an approach that’s fine if we expect the typography of the Web to remain limited to the same small set of fonts that have been widely used in the past, which of course is not the desired course for the future.

I don't think this is true:  an alternative way to look at how the
property works is what I described in
http://dbaron.org/log/20080613-firefox3-css :
  # the way I like to think about it is that is a way for style
  # sheets to pick font size by the size of the x-height rather than
  # the size of the font.
It's just a way to do this that is backwards-compatible with
browsers that don't support it.

> There’s a different approach that could be taken to all of this: for different fonts in a font stack, allow the developer to indicate a scaling factor—a percentage coefficient to apply to the nominal font size when that font gets used. Advantages that this would have include:

This requires *much* more work on the part of the author.

> In thinking about the behaviour of font-size-adjust and scenarios
> in which it would be used, I find David
> Baron’s<http://dbaron.org/log/20080613-firefox3-css#font-size-adjust>
> discussion enlightening: He describes trying to use it as a way to
> get monospaced text for code to “match” the size of the
> surrounding prose text; he concludes, “Unfortunately, I'm afraid
> the monospace font size preference is still interfering with
> things, so this may not be as useful as it could be.” I think part
> of what he’s running into is the reality that “matching” the size
> of two different fonts designed to different metrics is not a
> straightforward matter. Yet I think trying to treat x-height as a
> silver bullet to matching sizes incorrectly assumes that matching
> sizes can be straightforward. As is clear for non-Latin, matching
> based on x-height is not at all straightforward (if even ever
> useful). But even for Latin-only, Baron’s case study illustrates
> that it’s not always straightforward: he runs into some of the
> other factors (e.g. character width) that I mentioned above as
> other considerations of interest to the designer.

I was referring to a technical issue with Gecko browsers:  that we
actually have two different preferences for default font size, one
for monospace and one for non-monospace.  This was a solution
designed to solve the same problem as font-size-adjust, but the fact
that there were two different things trying to make adjustments for
the same reason led to incorrect results.  It is not a problem with
font-size-adjust itself.  I just haven't gotten around to replacing
the old solution with one based on font-size-adjust.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Tuesday, 3 May 2011 15:15:39 UTC