New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-fonts] avoid fallback from oblique to italic #9389
Comments
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. |
I agree. |
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:
Which resulted in which was closed by a427dc8 and re-reading that, it adds some clarity, no longer favors italic over synthetic oblique, but still allows fallback from oblique to italic! |
@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. |
@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. |
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. |
That is the specific point of this issue, yes: Fonts 4 currently explicitly allows that. |
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? |
That sounds like a good resolution to me and yes,I believe just Gecko would need to change here. |
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 |
I don't think it's correct that only Gecko is affected by this. Taking a trivial example,
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. |
Thanks for the clarification @jfkthame I misunderstood. Are browsers interested in making this change? |
I did look at the original discussion in: #8914 (comment), 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 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
So it would be tricky for us to make the proposed change: “Do not allow fallback to italic for oblique in font matching”. 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 |
OK, the call for consensus on the proposed resolution above has failed. Please continue the discussion. |
As there is resistance to making this change, it seems that a WPT is needed to test for the currently-specified fallback behavior. |
(this is a follow up from #8914 (comment))
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:
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:
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.
The text was updated successfully, but these errors were encountered: