[css-fonts] Clarify/reconsider interaction of new font-size-adjust options with writing modes

[jfkthame]

In #6160, we agreed to extend font-size-adjust to accept a metric to use as the basis for adjustment, rather than always relying on the ex-height.

Supporting ex (the default/existing behavior) and cap seems straightforward enough; these would typically be values provided in the font's OS/2 table.

However, ch is trickier, if we assume that it is intended to correspond to the ch unit, because the Units & Values definition of ch requires that it depends on writing-mode and text-orientation. If the ch value for font-size-adjust is interpreted similarly, this implies that the same font, with the same font-size and font-size-adjust properties in effect, will be sized very differently in vertical-upright mode vs horizontal or vertical-sideways.

Consider a typical Latin font where the horizontal-mode ch unit may be, for example, 0.5em; however, the vertical-upright ch unit is typically more like 1em. If the author uses font-size-adjust: ch 0.5, intending to try and maintain a reasonably consistent width of text, then any content with writing-mode: vertical-rl; text-orientation: upright will get this font reduced to half of the computed font-size, because its vertical-upright ch of 1em will be scaled down to 0.5.

While it could be argued this is "expected" -- it's what the author asked for, maintaining a consistent advance for the characters -- I think it would in fact be surprising and undesirable. I believe the natural expectation of authors will be that for a given font, the combination of font-size and font-size-adjust will give a consistent result, not a radically different used size depending on the writing-mode orientation.

I propose, therefore, that we explicitly define that the ch value for font-size-adjust refers to horizontal mode character advance.

Given that this contrasts with the ch unit, perhaps sharing the keyword is in fact unhelpful, and we should expand the font-size-adjust value to ch-width for clarity.

To allow authors to explicitly request the equivalent adjustment for vertical-upright mode, we could add a vertical-advance version, perhaps called vch, or ch-height if we expand the horizontal one as suggested above.

I think all the same issues apply to ic as well as ch, and we should resolve that similarly, probably by explicitly splitting the value into ic-width and ic-height. (In many cases, horizontal and vertical advances may be the same, such that the issue is irrelevant, but that is not universally the case. And I think having ic and ch treated differently in this regard would be even more confusing.)

(I note that in #6160 (comment), @fantasai mentioned that ic would be writing-mode dependent, but on reflection I think this is an undesirable result, especially when considered in conjunction with ch, where the behavior that results from being writing-mode-dependent seems really jarring.)

[frivoal]

I came to the same observation when reviewing #6382.

The advance measure of 0(upon which ch is based) is different depending on the writing mode (general case vs vertical upright). This could mean that specified with ch font-size-adjust is expect to stretch things by a different amount depending on the writing mode, but that seems unhelpful. As suggested above by @jfkthame we may want to clarify that font-size-adjust with ch works on the width of the 0 glyph in all writing-mode / text-orientation combination, instead the advance measure, which is defined to vary based on writing modes.

If we do want to be writing-mode sensitive, then ch probably should be paired with 2 rather than 1 numbers, the first one relating to the width of 0 and the second one to its height, the later being used in upright vertical contexts, and the first one otherwise. If so, the second one should probably be OK to omit, and when you do so, there should be no adjustment in the corresponding writing mode.

The situation is largely the same with the ic keyword and the 水 character. It might be less bad in practice if we get it wrong, as 水 is typically square or close to, while 0 is not, so the amount by which things are sized wrong would be less drastic, but it's stiff fundamentally the same issue.

[css-meeting-bot]

The CSS Working Group just discussed font-size-adjust vs writing modes, and agreed to the following:

• RESOLVED: Switch ic and ch to ic-width/ic-height/ch-width

The full IRC log of that discussion

<fantasai> Topic: font-size-adjust vs writing modes
<fantasai> github: https://github.com//issues/6288
<fantasai> jfkthame: Was working on implementing in Gecko, and it occurred to me that the behavior that falls out for the new ch and ic units probably isn't what we really want
<fantasai> jfkthame: if you set font-size-adjust: ch 0.4, for example, and then use vertical writing mode with upright typesetting
<fantasai> jfkthame: you'd get completely different scaling
<fantasai> jfkthame: Seems that would be unexpected and undesirable
<fantasai> jfkthame: Expectation would be that font + font-size-adjust should give consistent results
<fantasai> jfkthame: So my suggestion is that it applies in the horizontal axis
<fantasai> jfkthame: so not quite the same as the units
<fantasai> jfkthame: so maybe need to rename to make more explicit what they are
<fantasai> astearns: I think I'd like ch-width name
<fantasai> astearns: very explicit
<fantasai> jfkthame: We'd have the option of introducing a ch-height for vertical mode, but usage expected to be quite different
<fremy> fantasai: that would be more difficult than helpful
<fremy> fantasai: the vast majority of the authors wont need that second number
<fremy> fantasai: I would be ok with it if it is optional
<fremy> astearns: I think that was the proposal
<fantasai> fantasai: and sets to no effect
<fremy> fantasai: currently if you wanted to have an effect in the vertical axis, we have a syntax for two values
<fremy> fantasai: the disadvantage of that is that you might want different values for the different axes
<fremy> fantasai: but given few people would want to use two values
<fremy> fantasai: maybe we should just have one value and be clear about what it means
<fantasai> fantasai: and when would you know which one you want, if both are specified?
<fantasai> astearns: were we going to have ic-height and ic-width that can set at the same time?
<fantasai> jfkthame: no, just one at a time
<fantasai> astearns: So propoed resolution is to replace ic and ch with ic-width ic-height and ch-width
<fantasai> astearns: to lock things to the appropriate axis and make that explicit
<fantasai> fantasai: The one thing we might consider is adding 'ic' and having it compute to 'ic-width' or 'ic-height' as appropriate to the writing mode and then inherit as that computed value
<fantasai> fantasai: worth consideration, but I haven't thought about it much
<fantasai> astearns: but whatever value you add to that ic would be based on one or other metric, so unlikely to have single value that works for both
<fantasai> fantasai: unless you're using 1em, in which case no effect execpt for non-square fonts anyway...
<fantasai> jfkthame: [...]
<fantasai> jfkthame: Could look into it, but doesn't seem worth the complexity
<fantasai> RESOLVED: Switch ic and ch to ic-width/ic-height/ch-width

See official minutes