[css-fonts] Should font-style: oblique 0deg serialize as font-style: normal?

[nt1m]

In #2505, there was consensus to not serialize normal to oblique 0deg for backwards compat reasons, but interpolation should always use oblique 0deg.

This behavior is only implemented in Safari Technology Preview as it stands: https://wpt.fyi/results/css/css-fonts/animations/font-style-interpolation.html?label=master&label=experimental&aligned&q=font-style

Other browsers serialize as normal, which seems against the current specification: https://drafts.csswg.org/css-fonts-4/#font-style-prop

There are a couple of options:

• Keep spec as is, update WPT to match spec and Safari Tech Preview behavior
• Change the computed value of oblique 0deg to be normal all the time, even outside of animations (shortest serialization rule)
• Revert [css-fonts] value of font-style: normal vs. oblique 0deg; #2505, interpolate with normal as current WPT expect

cc @svgeesus @weinig @karlcow @jfkthame @tursunova @drott @tabatkins @fantasai

[svgeesus]

Seems clear that browsers won't update to what the CSSWG decided and spec says, unless wpt are updated to match.

[nt1m]

Sounds like we should update the WPT then.

[nt1m]

web-platform-tests/wpt#49892

[jfkthame]

I'm not sure I agree with this.

In #2505, there was consensus to not serialize normal to oblique 0deg for backwards compat reasons, but interpolation should always use oblique 0deg.

Interpolation accepts normal as if it were oblique 0deg, allowing interpolation between normal and arbitrary oblique values; but I don't think that says anything about how the value serializes?

Other browsers serialize as normal, which seems against the current specification: https://drafts.csswg.org/css-fonts-4/#font-style-prop

I don't see anything in https://drafts.csswg.org/css-fonts-4/#font-style-prop indicating that font-style should serialize differently when it is being animated from how the same value serializes otherwise.

If I animate font-style from oblique -10deg to oblique 10deg, the animated value at the half-way point will pass through a value that is equivalent to font-style: normal, and I'd still expect it to serialize as such.

It's not clear to me that the resolution in #2505 ever intended browsers to serialize the value as oblique 0deg instead of normal. We resolved to:

change font-style animation behavior so that 'normal' can animate with 'oblique <num>'

(which browsers have implemented), but that's specifically about animation behavior, not about serialization.

The spec says that the animation type is the computed value type, for which we agreed that the "0 degree" value should (continue to) serialize as normal.

[nt1m]

Interpolation accepts normal as if it were oblique 0deg, allowing interpolation between normal and arbitrary oblique values; but I don't think that says anything about how the value serializes?

The discussion IRC log specifically referred to what I mentioned.

<dael> myles: Computed value of normal should be oblique 0. Computed value of oblique with nothing...
<dael> fantasai: I don't htink it' sbackwards compat.

---

I don't see anything in https://drafts.csswg.org/css-fonts-4/#font-style-prop indicating that font-style should serialize differently when it is being animated from how the same value serializes otherwise.

This is how many of us have interpreted the following:

by computed value type; [normal](https://drafts.csswg.org/css-fonts-4/#valdef-font-style-normal) animates as oblique 0deg

[jfkthame]

Interpolation accepts normal as if it were oblique 0deg, allowing interpolation between normal and arbitrary oblique values; but I don't think that says anything about how the value serializes?

The discussion IRC log specifically referred to what I mentioned.

<dael> myles: Computed value of normal should be oblique 0. Computed value of oblique with nothing...
<dael> fantasai: I don't htink it' sbackwards compat.

Yes, Myles suggested that the "computed value of normal should be oblique 0"; but then Elika objects that she doesn't think it will be backwards compatible, and indeed the resolution at the end of the discussion explicitly says "leave font-style computed values as-is" (in other words, Myles's suggestion here was not adopted, AIUI).

[nt1m]

Yeah, there was consensus to not serialize normal to oblique 0deg for backwards compat reasons. But whether oblique 0deg should serialize to normal has not really been resolved on.

[jfkthame]

According to the spec, normal is essentially a convenience value that means the same as oblique 0deg:

This represents an oblique value of "0".

So surely they should serialize the same. The shortest-form principle (as well as backwards-compat concerns) dictates that this should be normal. And AFAICS that's what shipping versions of all the engines currently do.

Is there a compelling reason to change this behavior? If it's just that the spec is a bit confusing (hence this discussion!), I suggest we add a note clarifying that oblique 0deg always computes to normal (including during animation; the remark that "normal animates as oblique 0deg" refers to how this value is interpolated with other oblique values, it does not alter how it serializes).

[nt1m]

Can we just say normal and oblique 0deg are aliases? The current wording as it stands is very confusing.

[fantasai]

I think what you're saying is that normal computes to oblique 0deg and oblique 0deg serializes as normal. Yes?

[weinig]

While discussing/adding serialization logic to the spec, please also consider if the case of oblique 14deg and whether that should serialize as oblique due to: "The lack of an <angle> represents 14deg."

[nt1m]

While discussing/adding serialization logic to the spec, please also consider if the case of oblique 14deg and whether that should serialize as oblique due to: "The lack of an <angle> represents 14deg."

Given this value used to be 20deg, I would tend towards no, but I don't feel super strongly.

[emilio]

What do browsers do here?

[svgeesus]

I think what you're saying is that normal computes to oblique 0deg and oblique 0deg serializes as normal. Yes?

That would be my preferred outcome.

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts] Should `font-style: oblique 0deg` serialize as `font-style: normal`?, and agreed to the following:

• RESOLVED: 'normal' and 'oblique 0deg' are the same value, and serialize as 'normal'

The full IRC log of that discussion

<TabAtkins> weinig: When animating from 'normal' to 'oblique' thru 'oblique 0', should we serialize that as 'normal' or not?
<TabAtkins> weinig: It seems more straightforward to always serialize oblique as 'oblique 0', but shortest-serialization does suggest we shoudl serialize it as 'nromal'
<emilio> q+
<TabAtkins> weinig: tests are inconsistent
<florian> q?
<florian> q+
<astearns> ack emilio
<TabAtkins> weinig: rather, they were inconsistent. now they always serailize 'nromal' as 'oblique 0' when animating, but as 'nromal' otherwise
<TabAtkins> weinig: there was a decision a while back to animate 'normal' as 'oblique 0'
<TabAtkins> ChrisL: fantasai had suggested we treat the *computed value* of nromal as oblique 0, but should serialize as normal
<TabAtkins> weinig: we could do that, so oblique 0 always serializes as normal
<ChrisL> normal computes to oblique 0deg and oblique 0deg serializes as normal.
<TabAtkins> emilio: question is if normal and oblique 0 are same value or not. if they're the same, we shoudl serialize consisntently. and for compat 'nromal' has to serialize as 'normal', so we shoudl do the same with 'oblique 0'
<TabAtkins> weinig: totally doable, jsut need to state it
<astearns> ack florian
<TabAtkins> florian: i agree with that, and it's not just compat arguing for it, also SSP
<TabAtkins> florian: so multiple args to serialize them both as 'normal'
<TabAtkins> emilio: fwiw right now in gecko they're not the same value, but when you animate you turn 'normal' into 'oblique 0'. it's kinda a special case, would be fine to remove it
<astearns> ack dbaron
<TabAtkins> dbaron: trying to remember chris's points about font matching earlier
<TabAtkins> dbaron: is the idea that 'oblique .001' you'll search for an oblique closest to that slant, but 'oblique 0' you won't search? is there that discontinuity?
<TabAtkins> ChrisL: i think so, yes
<TabAtkins> dbaron: given the discontinuity exists, the serialization seems reasonable
<TabAtkins> (clearly need to distinguish oblique 0 from oblique -0)
<TabAtkins> astearns: if we agree on this, it'd be a WPT change and impl chnage?
<astearns> closest to that slant direction
<TabAtkins> weinig: yes, but trivial
<TabAtkins> emilio: yeah relatively little compat impact
<TabAtkins> astearns: so for parsimony, resolution is 'normal' and 'oblique 0' are the same value, and serialize as 'normal'
<TabAtkins> jfkthame: imagine a font family that contains a fixed regular face and a variable oblique face
<TabAtkins> jfkthame: the slant might be zero
<TabAtkins> jfkthame: it seems liek saying they're the same we're losing the ability to differentiate between those two faces
<TabAtkins> jfkthame: they might look different at the 0deg angle
<TabAtkins> astearns: that's correct
<emilio> q+
<TabAtkins> astearns: is there utility in being able to pick the new version with a 0deg slant that we're locking out with this decision?
<astearns> ack emilio
<TabAtkins> weinig: i don't know how to interpret the slnt table, it says 0 is required to be the "regular" value. i don't think it's even a meaningful disinction then in opentype
<TabAtkins> emilio: you already lose that distinction when you animate. since we do want to allow the animation from normal to oblique values, it would feel weird if you animate back and forth and you end up with a different font.
<TabAtkins> emilio: I don't think that edge case (which might nto even matter in practice, given sam's comment) i don't think it's worth reintroducing the distinction
<TabAtkins> astearns: do you have specific fonts in mind, jfkthame ?
<ChrisL> q+
<TabAtkins> jfkthame: no, just trying to envision what it means
<TabAtkins> astearns: is this enough to object to the resolution, or would you be okay with us taking the resoltuion since we dont' have evidence of the problem being an author issue?
<TabAtkins> jfkthame: not going to object
<TabAtkins> jfkthame: i think if it exists at all it's a niche thing, just wanted to bring the question up
<astearns> ack ChrisL
<TabAtkins> ChrisL: i read the opentype spec as trying to prevent that conflict from happening
<TabAtkins> ChrisL: they're tyring to make sure that if you have "regular" in your face, you shoudl be using that for 0 SLNT
<TabAtkins> ChrisL: so it shoudln't happen for well-behaved fonts
<TabAtkins> RESOLVED: 'normal' and 'oblique 0deg' are the same value, and serialize as 'normal'
<TabAtkins> jfkthame: minor followup, how does 'oblique 14deg' serialize
<TabAtkins> ChrisL: I think it should be oblique 14deg
<TabAtkins> ChrisL: at one point the default was 20deg, we changed it. would prefer to avoid that ambiguity.
<TabAtkins> fantasai: that's not backwards compatible tho
<TabAtkins> weinig: other way around, should oblique 14deg serialize as oblique
<TabAtkins> fantasai: can a font have a preferred oblique angle?
<florian> q?
<TabAtkins> weinig: the spec says ti's always 14deg
<TabAtkins> florian: the spec says that if you synthesize, you use 14deg; does it say that omitting *uses* 14deg?
<TabAtkins> weinig: yes. [gives quote]
<TabAtkins> florian: okay
<TabAtkins> emilio: having `oblique` mean something different from a specific angle woudl also make interpolation harder
<TabAtkins> florian: maybe we should have `oblique from-font`?
<TabAtkins> weinig: I'll file a new issue.