- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Jan 2025 14:12:12 +0000
- To: public-css-archive@w3.org
I'm not sure I agree with this. > In https://github.com/w3c/csswg-drafts/issues/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 https://github.com/w3c/csswg-drafts/issues/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`. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11430#issuecomment-2569278170 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 January 2025 14:12:13 UTC