[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.