W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2016

[csswg-drafts] [css-fonts-4] font matching algorithm should not favor italic as a fallback for oblique

From: litherum via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Sep 2016 22:53:28 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-178482014-1474498406-sysbot+gh@w3.org>
litherum has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-fonts-4] font matching algorithm should not favor italic as a 
fallback for oblique ==
[Migrated](https://github.com/litherum/csswg-drafts/issues/3) on 
behalf of @jfkthame:

Back in the days of CSS2.1, the spec 
[said](https://www.w3.org/TR/CSS21/fonts.html#propdef-font-style):

> A value of 'normal' selects a font that is classified as 'normal' in
 the UA's font database, while 'oblique' selects a font that is 
labeled 'oblique'. A value of 'italic' selects a font that is labeled 
'italic', or, if that is not available, one labeled 'oblique'. 

Note that it does *not* suggest that an italic face should be used 
when oblique is specified.

However, in CSS Fonts 3, things have 
[changed](https://www.w3.org/TR/css-fonts-3/#font-style-prop):

> Values have the following meanings:
> 
> normal
>     selects a face that is classified as a normal face, one that is 
neither italic or obliqued 
> italic
>     selects a font that is labeled as an italic face, or an oblique 
face if one is not 
> oblique
>     selects a font that is labeled as an oblique face, or an italic 
face if one is not 

So now, 'italic' falls back to oblique (as before), *and* 'oblique' 
falls back to italic (changed behavior).

(This difference is also reflected in the Font Matching Algorithm 
described in the two spec versions.)

I think this change was a mistake. When 'oblique' is requested but no 
actual oblique is present, a better fallback than the italic face 
would be a synthetically-slanted version of the regular face.

According to the reporter in [this Mozilla 
bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1303580), browsers 
currently differ on this, which leads me to suspect that a spec change
 here (and corresponding changes to the browsers that follow the 
current CSS Fonts behavior) will be unlikely to break the web in any 
substantial way.

(This isn't directly linked with variation fonts, but as we're 
re-examining the font properties and matching algorithm anyway, and 
variations do have implications for font-style, it seemed like the 
right time to bring it up.)


Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/514 using your GitHub 
account
Received on Wednesday, 21 September 2016 22:53:35 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:03 UTC