[css-fonts-5] Computed value of `font-size-adjust: from-font`

[jfkthame]

The current spec says that the computed value of font-size-adjust is

the keyword none, or a pair of a metric keyword and a <number>

and for the from-font keyword it confirms that this

Computes to the <number> corresponding to the specified metric of the first available font.

As I'm looking at implementing this in Gecko, the question arose as to whether the behavior in the spec is really what is desired here.

Note that the behavior currently implemented in WebKit (and expected by a WPT testcase) is different. Using current Safari Technology Preview:

> document.body.style.fontSizeAdjust = "from-font"
< "from-font"
> window.getComputedStyle(document.body).fontSizeAdjust
< "from-font"

we see that the computed value is the from-font keyword; it is not resolved to a <number> at computed-value time.

@litherum @svgeesus Should the spec be changed to reflect this, or should we file a bug against WebKit and proceed with implementing what the spec says?

[jfkthame]

After experimenting with from-font a bit, I'm persuaded that the behavior in the spec (computing from-font to a number based on the element's "first available font", so that descendants will inherit the number, not the keyword) is the right thing to do.

Consider content such as

  <p style="font-family:serif">Here's some text with a bit of <tt>typewriter text</tt> in it.</p>
  <p style="font-family:sans-serif">Here's some text with a bit of <tt>typewriter text</tt> in it.</p>

Depending on the fonts in use, the "typewriter" (monospaced) text often looks somewhat mis-sized compared to the surrounding serif or sans-serif. This is somewhere font-size-adjust should be able to help.

We could set font-size-adjust on the paragraphs with an explicit value:

  <p style="font-family:serif; font-size-adjust:0.5">Here's some text with a bit of <tt>typewriter text</tt> in it.</p>
  <p style="font-family:sans-serif; font-size-adjust:0.5">Here's some text with a bit of <tt>typewriter text</tt> in it.</p>

which works to harmonize the monospaced font with its surroundings, but also resizes the main font of the paragraph, unless the number is chosen such that it exactly matches that font's ex-height factor.

Time for from-font to come to the rescue! Using this, we can set the font-size-adjust factor without having to manually determine the exact value for the main font in use (which we might not even know). So let's do it:

  <p style="font-family:serif; font-size-adjust:from-font">Here's some text with a bit of <tt>typewriter text</tt> in it.</p>
  <p style="font-family:sans-serif; font-size-adjust:from-font">Here's some text with a bit of <tt>typewriter text</tt> in it.</p>

This should ensure that the main paragraph font is untouched by font-size-adjust, while the embedded monospace text gets harmonized with it.

But that only works if from-font is computed to a number, so that the <tt> element inherits the factor that was computed from the metrics of the surrounding paragraph's font. If it were to inherit the keyword value from-font, it would then set its own factor based on the monospace font's metrics, and no adjustment would happen!

So the spec is correct to say that from-font computes to a number.

[jfkthame]

I've filed https://bugs.webkit.org/show_bug.cgi?id=259551 to report the current webkit behavior as incorrect.

(I think this issue should be closed with no change, but would still appreciate confirmation from the spec editors @litherum @svgeesus of this understanding.)

[svgeesus]

@litherum @svgeesus Should the spec be changed to reflect this, or should we file a bug against WebKit and proceed with implementing what the spec says?

As you have since conclusively demonstrated, the spec is correct and so bugs should be filed on WebKit (already done I see, thanks) and a PR to change the tests on WPT.

[jfkthame]

Thanks, Chris. I have a patch to fix the WPT tests as part of the Gecko bug to implement from-font at https://bugzilla.mozilla.org/show_bug.cgi?id=1708240, so that'll be incoming shortly.

[css-meeting-bot]

The CSS Working Group just discussed font-size-adjust: from-font computed value, and agreed to the following:

• RESOLVED: Close no change, update WPT

The full IRC log of that discussion

<fantasai> Topic: font-size-adjust: from-font computed value
<fantasai> github: https://github.com//issues/9050
<TabAtkins> This one also straightforward, +1 to close no change
<fantasai> jfkthame: Came up when implementing in Gecko. I think spec text is fine, but conflicts with what WebKit implemented and WPT tests they landed
<fantasai> jfkthame: Chris agrees to close issue as no change
<fantasai> jfkthame: main question is whether WebKit wants to resist that in any way
<fantasai> jfkthame: But I think they are currently working on fixing their implementation
<fantasai> jfkthame: so probably fine to close
<fantasai> astearns: objections to closing no change?
<fantasai> astearns: and you'll fix the WPT
<fantasai> jfkthame: yes, will merge later
<fantasai> RESOLVED: Close no change, update WPT

[shivamidow]

window.getComputedStyle(document.body).fontSizeAdjust
"from-font"

Regarding the computed style for from-font, do we have a source that describes that the returned value from serialization should be a resolved number? text-underline-position and text-decoration-thickness can have from-font, but they return the from-font identifier as a computed style, not a real number. If we serialize from-font for font-size-adjust with a real number, that is inconsistent with text-underline-position: from-font and text-decoration-thickness: from-font.

[jfkthame]

window.getComputedStyle(document.body).fontSizeAdjust
"from-font"

Regarding the computed style for from-font, do we have a source that describes that the returned value from serialization should be a resolved number?

As noted in #9050 (comment), the spec is quite clear that from-font computes to a number.