Re: [csswg-drafts] [css-fonts-5] font-size-adjust with missing metrics (#6384)

@svgeesus wrote:
> @jfkthame I had considered that case to evaluate to 'missing'.

@jfkthame wrote:
> (2) When font-size-adjust specifies the from-font keyword, but the [first available font](https://drafts.csswg.org/css-fonts-4/#first-available-font) doesn't provide the relevant metric, should we (a) treat this as none, so no adjustment will be applied to fallback fonts; (b) use the fallback value of the metric for the computed adjustment factor; or (c) look for the first available font that is able to provide the desired metric?

For 2, I agree with @svgeesus. I don't think we need a new concept, such as "first available font that has specified metric".  To me `font-size-adjust` not doing any adjustment is the most logical outcome, given the intention of the property.

@jfkthame I see your point about the fallback sizing of Arabic dropping to a small size in this example, but I find this example very synthetic, I'll explain below why:

One more point, about the prevalence of missing metrics:
@jfkthame wrote:
> [...Arabic font not having a cap height metric...] (which isn't unreasonable, as the concept has no clear meaning for Arabic script)

I quickly checked Segoe UI (default Arabic windows font), Geeza Pro (Mac default Arabic), Noto Nastaliq, Noto Sans Arabic - and they all have a cap height. I'd argue a font maker has to provide a less up-to-date `OS/2` table in order to intentionally not provide a cap height. IMHO the situations we talk about here are less likely to occur at all.

Do we still agree that the intent of font-size-adjust is to harmonize a certain metric towards the primary font, in order to a) improve legibility, b) reduce cumulative layout shift? (At least both examples in the spec compute a base value from the primary font, and use font-size adjust to normalize fallback fonts towards that.)

In my opinion, usage of font-size adjust for extreme scaling away from the `font-size` is not a use-case that this intended for. We might even want to consider scale factor limits for the scaling equation. 

From my perspective, it is okay if your example in https://github.com/w3c/csswg-drafts/issues/6384#issuecomment-2006987845 does not scale the Arabic part, as I would interpret it as incorrect usage of the property, and that is a useful signal to the content author during authoring. 

Intended usage of the property, or where the property works best and in a predictable way if a) the value is calibrated to the primary font by the author in the sense that it does not alter the primary fonts' used font size  b) the fallback fonts are known and have been visually checked to provide a good outcome for a given normalization `font-size-adjust` value. 

(Not using the property for overriding/scaling away from `font-size` also avoids breakage where a font has an incorrectly specified metrics.)

When used in this way, I don't see proof that using a heuristic or fallback value (like approximating cap-height by something else) would achieve a better outcome than performing no adjustment.

If `font-size-adjust` is used this way, a missing metric in the worst case - leads to a minor perceived font size discrepancy between primary font and fallback fonts. That's why I think specifying the behavior for (1) and (2) as "no adjustment on missing metric" is reasonable. 

-- 
GitHub Notification of comment by drott
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6384#issuecomment-2007458859 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 19 March 2024 15:13:14 UTC