[css-fonts] avoid fallback from oblique to italic

[frivoal]

(this is a follow up from https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1651137267)

When people ask for italic, they typically need to make some kind of semantic distinction from other non italic text. Falling back to oblique text when an italic font-face is not available is reasonable.

However, when people specifically ask for an oblique font, the converse is not true. People asking for oblique specifically want oblique, and falling back to italic is not expected. In particular, unlike italic which is a distinctive style, synthesizing oblique is very doable, and synthetic oblique is much more likely to satisfy the author's expectation than falling back from oblique to italic.

The definition of both values supports this as well:

• italic: Matches against a font that is labeled as an italic face, or an oblique face if one does not exist.
• oblique: Controls matching against an oblique face. […disucssion of slant…] If no oblique faces exist, and font-synthesis-style has the value auto, a synthetic oblique face will be generated.

So far so good.

However, the subsequent paragraph in the spec is a little ambiguous, but suggest that when picking a font based on a requested angle, priority is given to the angle, and might select from both italic and oblique, regardless of which style is selected:

A font family might contain no italic or oblique faces, only an italic face and no oblique, only an oblique face and no italic, both an oblique and an italic, multiple oblique faces at various angles, or various combinations thereof. The font matching routine will select a font to use which is closest to the requested angle.

I would initially have suggested an editorial clarification ( maybe "[…]closest to the requested angle within the requested style, before acceptable fallbacks are tried."), but upon further inspection, it seems that the actual font matching routine does indeed allow fallback from oblique to italic, in steps 4 and 6 of "If the value of font-style is oblique […]".

So, I would also suggest that these steps 4 and 6 be removed. The vast majority of the time, they should be be reached anyway, as the font sythesis of step 3 will terminate the routine, but in cases where authors have specifically called for an oblique font and no synthesis, swapping in italics isn't what they're calling for.

[frivoal]

Note: falling back from oblique to italic was introduced in css-fonts-3, but CSS2.1 did not allow it). However, even though css-fonts-3 is a REC, there is no test in WPT supporting fallback from oblique to italic.

[svgeesus]

these steps 4 and 6 be removed. The vast majority of the time, they should be be reached anyway, as the font sythesis of step 3 will terminate the routine, but in cases where authors have specifically called for an oblique font and no synthesis, swapping in italics isn't what they're calling for.

I agree.

[svgeesus]

Seven years ago, on a Mozilla bug where the OP wanted to avoid fallback from oblique to italic but the bug was closed because Firefox was spec-compliant in doing so, @jfkthame wrote:

Note that this -does- call for use of an 'italic' face as fallback when 'oblique' is not present. Therefore, IE11 and Firefox are in conformance with the current spec, while Chrome and Edge are following the older CSS2 spec.

However, I'd encourage you to raise this as an issue with the CSS Working Group (e.g by email to www-style@w3.org, or by opening an issue at https://github.com/w3c/csswg-drafts/tree/master/css-fonts), as I think it would actually be preferable for the browser to synthesize an oblique face when 'oblique' is requested, rather than using an italic face.

Which resulted in

• https://github.com/w3c/csswg-drafts/issues/514

which was closed by https://github.com/w3c/csswg-drafts/commit/a427dc8e1025fed71131db8a106aa420e640ea2c and re-reading that, it adds some clarity, no longer favors italic over synthetic oblique, but still allows fallback from oblique to italic!

[svgeesus]

We also have the somewhat confusing:

For the purposes of font matching, User agents may treat italic as a synonym for oblique. For user agents that treat these values distinctly, synthesis must not be performed for italic.

[svgeesus]

@drott would be good to get your input on this. @jfkthame I assume your opinion remains the same.

I therefore support the proposal to remove steps 4 and 6 from "If the value of font-style is oblique and the requested angle is greater than or equal to 11deg," (the two steps that describe checking italic when oblique was requested).

In consequence, the figure in the example following that section would be edited to remove the "check italic" dashed line, and the caption edited to remove mentions of falling back to italic.

[svgeesus]

@astearns this might be suitable for an async resolution, rather than take up telcon time to read out the proposal. There are no dissenting voices in this issue, currently.

[svgeesus]

An additional consequence would be to delete the text

For the purposes of font matching, User agents may treat italic as a synonym for oblique.

from the font-style property

[jfkthame]

An additional consequence would be to delete the text

For the purposes of font matching, User agents may treat italic as a synonym for oblique.

from the font-style property

I haven't thought this through in detail, but "may treat italic as a synonym for oblique" would kinda still be true provided font-synthesis-style isn't disabled, wouldn't it? The interesting point - which might be worth calling out explicitly - is that the inverse is not true: user agents must not treat oblique as a synonym for italic.

[svgeesus]

The interesting point - which might be worth calling out explicitly - is that the inverse is not true: user agents must not treat oblique as a synonym for italic.

That is the specific point of this issue, yes: Fonts 4 currently explicitly allows that.

[astearns]

Would a proposed resolution of “Do not allow fallback to italic for oblique in font matching” work? Is Gecko the only engine that would need to change for this?

[svgeesus]

That sounds like a good resolution to me and yes,I believe just Gecko would need to change here.

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Do not allow fallback to italic for oblique in font matching

[jfkthame]

Would a proposed resolution of “Do not allow fallback to italic for oblique in font matching” work? Is Gecko the only engine that would need to change for this?

I don't think it's correct that only Gecko is affected by this.

Taking a trivial example,

data:text/html,<div style="font:20px Times">hello <span style="font-style:oblique">oblique</span> world

my understanding of this resolution is that the browser should not render the word "oblique" using Times Italic; it must instead use an oblique face, synthesizing one it if there isn't a real oblique available.

Currently, all of Chrome, Safari and Firefox give me Times Italic there, so they will all need to change to implement this resolution.

[svgeesus]

Thanks for the clarification @jfkthame I misunderstood. Are browsers interested in making this change?

[astearns]

@drott @fantasai could you comment (or add an emoji to the proposed resolution)?

[drott]

I did look at the original discussion in: https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1649678597, which was original about controlling the synthetic slant angle (right-leaning vs. left-leaning). The test case on that issue also relies on system fonts and then on availability of system fonts in a particular style.

I am a bit confused as to what actual case we are trying to address, I thought the original issues is about slant direction. With this proposed resolution, I don't think we're getting closer to enabling left-leaning slant, or are we and I missing something?

So here, the proposed resolution is: We should not fallback to italic when oblique is requested and instead prefer synthesis.

IMO the general fix for getting the correct intended presentation is to use good fonts. When a good portfolio of fonts is provided as web fonts, likely one label in the @font-face declarations for the purposes of font matching is sufficient, and it does not really matter whether that's italic or oblique. Here, italic and oblique would be in conflict if within one declared family for "oblique" synthesis would be preferred, for "italic" the crafted glyphs would be preferred.

In our implementation, we don't have a strict distinction about "intent to synthesize italic" vs. "intent to synthesize oblique", or in other words, we rely on

For the purposes of font matching, User agents may treat italic as a synonym for oblique.

So it would be tricky for us to make the proposed change: “Do not allow fallback to italic for oblique in font matching”. I am also hesitant to move in the direction of more synthesis vs. less.

For the slant angle direction problem, I think this can be solved well with variable fonts with a slnt axis. I am also open to looking into better control of the synthesized slant angle direction, as in the original request. But at this point, I don't see how the proposed resolution brings us closer to it, other than avoiding dropping to italic, but then still producing an incorrect slant angle direction in the synthesis.

[astearns]

OK, the call for consensus on the proposed resolution above has failed. Please continue the discussion.

[svgeesus]

Note: falling back from oblique to italic was introduced in css-fonts-3, but CSS2.1 did not allow it). However, even though css-fonts-3 is a REC, there is no test in WPT supporting fallback from oblique to italic.

As there is resistance to making this change, it seems that a WPT is needed to test for the currently-specified fallback behavior.