- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 19:06:08 +0000
- To: public-css-archive@w3.org
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'` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> weinig: When animating from 'normal' to 'oblique' thru 'oblique 0', should we serialize that as 'normal' or not?<br> <TabAtkins> weinig: It seems more straightforward to always serialize oblique as 'oblique 0', but shortest-serialization does suggest we shoudl serialize it as 'nromal'<br> <emilio> q+<br> <TabAtkins> weinig: tests are inconsistent<br> <florian> q?<br> <florian> q+<br> <astearns> ack emilio<br> <TabAtkins> weinig: rather, they were inconsistent. now they always serailize 'nromal' as 'oblique 0' when animating, but as 'nromal' otherwise<br> <TabAtkins> weinig: there was a decision a while back to animate 'normal' as 'oblique 0'<br> <TabAtkins> ChrisL: fantasai had suggested we treat the *computed value* of nromal as oblique 0, but should serialize as normal<br> <TabAtkins> weinig: we could do that, so oblique 0 always serializes as normal<br> <ChrisL> normal computes to oblique 0deg and oblique 0deg serializes as normal.<br> <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'<br> <TabAtkins> weinig: totally doable, jsut need to state it<br> <astearns> ack florian<br> <TabAtkins> florian: i agree with that, and it's not just compat arguing for it, also SSP<br> <TabAtkins> florian: so multiple args to serialize them both as 'normal'<br> <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<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: trying to remember chris's points about font matching earlier<br> <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?<br> <TabAtkins> ChrisL: i think so, yes<br> <TabAtkins> dbaron: given the discontinuity exists, the serialization seems reasonable<br> <TabAtkins> (clearly need to distinguish oblique 0 from oblique -0)<br> <TabAtkins> astearns: if we agree on this, it'd be a WPT change and impl chnage?<br> <astearns> closest to that slant direction<br> <TabAtkins> weinig: yes, but trivial<br> <TabAtkins> emilio: yeah relatively little compat impact<br> <TabAtkins> astearns: so for parsimony, resolution is 'normal' and 'oblique 0' are the same value, and serialize as 'normal'<br> <TabAtkins> jfkthame: imagine a font family that contains a fixed regular face and a variable oblique face<br> <TabAtkins> jfkthame: the slant might be zero<br> <TabAtkins> jfkthame: it seems liek saying they're the same we're losing the ability to differentiate between those two faces<br> <TabAtkins> jfkthame: they might look different at the 0deg angle<br> <TabAtkins> astearns: that's correct<br> <emilio> q+<br> <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?<br> <astearns> ack emilio<br> <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<br> <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.<br> <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<br> <TabAtkins> astearns: do you have specific fonts in mind, jfkthame ?<br> <ChrisL> q+<br> <TabAtkins> jfkthame: no, just trying to envision what it means<br> <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?<br> <TabAtkins> jfkthame: not going to object<br> <TabAtkins> jfkthame: i think if it exists at all it's a niche thing, just wanted to bring the question up<br> <astearns> ack ChrisL<br> <TabAtkins> ChrisL: i read the opentype spec as trying to prevent that conflict from happening<br> <TabAtkins> ChrisL: they're tyring to make sure that if you have "regular" in your face, you shoudl be using that for 0 SLNT<br> <TabAtkins> ChrisL: so it shoudln't happen for well-behaved fonts<br> <TabAtkins> RESOLVED: 'normal' and 'oblique 0deg' are the same value, and serialize as 'normal'<br> <TabAtkins> jfkthame: minor followup, how does 'oblique 14deg' serialize<br> <TabAtkins> ChrisL: I think it should be oblique 14deg<br> <TabAtkins> ChrisL: at one point the default was 20deg, we changed it. would prefer to avoid that ambiguity.<br> <TabAtkins> fantasai: that's not backwards compatible tho<br> <TabAtkins> weinig: other way around, should oblique 14deg serialize as oblique<br> <TabAtkins> fantasai: can a font have a preferred oblique angle?<br> <florian> q?<br> <TabAtkins> weinig: the spec says ti's always 14deg<br> <TabAtkins> florian: the spec says that if you synthesize, you use 14deg; does it say that omitting *uses* 14deg?<br> <TabAtkins> weinig: yes. [gives quote]<br> <TabAtkins> florian: okay<br> <TabAtkins> emilio: having `oblique` mean something different from a specific angle woudl also make interpolation harder<br> <TabAtkins> florian: maybe we should have `oblique from-font`?<br> <TabAtkins> weinig: I'll file a new issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11430#issuecomment-2625344582 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 19:06:09 UTC