- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Aug 2017 13:32:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Animating font weight`, and agreed to the following resolutions: * `RESOLVED: font-weight matching described before` * `RESOLVED: Font selection algorithm has different behavior during animation than Fonts 3; we will add a note to that affect in Fonts 4.` <details><summary>The full IRC log of that discussion</summary> <fremy> Topic: Animating font weight<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1579<br> <fremy> myles_: two things here<br> <fremy> myles_: 1. requested font weight<br> <fremy> myles_: 2. available options in the font<br> <fremy> myles_: then algorithm match one to the others<br> <fremy> myles_: for historical reasons, if you want 400 and it is not possible<br> <fremy> myles_: search will be 300, then 500, then 200, then ...<br> <fremy> myles_: variables fonts can have much more arbitrary values<br> <fantasai> 500, then 300, then 200 I think<br> <fremy> myles_: so I tried to come up with a solution for this<br> <fantasai> s/this/generalizing this/<br> <fremy> myles_: (connecting laptop to tv screens)<br> <fremy> myles_: the generalization i came up with: 400, then 500, then any value between 400 and 300, then any value between 400 and 600, etc<br> <fremy> fantasai: why not directly 400 -> 500 instead of 400 then discretely 500<br> <fremy> fantasai: doesn't seem very logical<br> <fremy> TabAtkins: the old model did that<br> <fremy> fantasai: but you could not express 430, it needed to be hundred multiples<br> <fremy> fantasai: the goal of the algorithm was that 400 and 500 were very common values<br> <fremy> fantasai: but 300 is often lightweight<br> <fremy> fantasai: this proposal preserves the compat, but not the spirit<br> <fremy> fantasai: I would prefer to connect the 400 -> 500 range<br> <fremy> TabAtkins: yes, it is less weird<br> <fremy> myles: if there is concensus, i am ok with this<br> <fremy> fantasai: this would evolve the old algorithm, not run some algorithm after it<br> <fremy> fantasai: proposal means if we did 400 then 500 then 300, now we do 400 -> 500, then 500 -> 300, ...<br> <fremy> fantasai: obviously some values will not match<br> <fantasai> basically play "connect the dots" with the old search points<br> <fremy> fantasai: because they have been searched already<br> <fantasai> which might go over some ranges multiple times, but of course the UA would optimize those out<br> <fremy> (whiteboard discussion)<br> <fremy> (the discussion seems to be about what fantasai's idea does if you search for 450 not 400)<br> <fremy> (and related cases like 250 or 550)<br> <Rossen> [fantasai and myles are having hell of a time connecting dots and lines on the white board]<br> <TabAtkins> Split the weights into three categories:<br> <TabAtkins> light - < 400<br> <TabAtkins> medium - 400 <= x <= 500<br> <TabAtkins> bold - > 500<br> <TabAtkins> For light, first search from x => 0, then x => 1000<br> <TabAtkins> For bold, first search from x => 1000, then x => 0<br> <TabAtkins> For medium, several possiblities.<br> <TabAtkins> Never mind, bolder is better, so medium's category is: search x=>500, then x => 0, then x => 1000<br> <fremy> RESOLVED: font-weight matching described before<br> <TabAtkins> ScribeNick: TabAtkins<br> <TabAtkins> myles: Previously you could animate font-weights, even tho they weren't numbers.<br> <TabAtkins> myles: You animated a number, then rounded to nearest 100, *then* invoked the font selection algo.<br> <TabAtkins> myles: So at a particular value of time, say your animation was at font-weight:540. You'd first round to 500, then run font-selection.<br> <TabAtkins> myles: For variable fonts, you don't have to round. This is a good thing.<br> <TabAtkins> myles: But rounding might change which case you fall into.<br> <TabAtkins> fantasai: And when animating between 401 and 450, rounding would make you choose the 400 font, but our new thing would choose the 500 font.<br> <TabAtkins> myles: So two options: undo what we just did and make it more complicated...<br> <TabAtkins> myles: Or say that animating font-weights before variable fonts wasn't often used, and just accept the behavior change.<br> <TabAtkins> fantasai: I think there's not much objection to computing font-weight and its animation to be a general integer.<br> <TabAtkins> fantasai: But for impls that don't do variable fonts, do we want them to accept any value, or should they still do the rounding?<br> <TabAtkins> dbaron: There are fonts with more than just 100, 200, etc weights; seems like it would be better to make that work.<br> <TabAtkins> dauwhe: I have a font with weights spaced every 5.<br> <TabAtkins> dbaron: So I think we should just make the change; we'll see if there's any problem.<br> <TabAtkins> myles: I think we alreayd have an old resolution to let weight accept any integer, actually.<br> <TabAtkins> dbaron: Does the spec really mean <number> rather than <integer>?<br> <TabAtkins> myles: <number> is right; variables axises can accept any float in the range.<br> <TabAtkins> fantasai: So Fonts 3 needs to be updated; do we want to allow it at parse time too?<br> <TabAtkins> dbaron: I dont' think Fonts 3 needs updating; this is a new feature, the property just supports more values than it used to.<br> <TabAtkins> fantasai: That's fair.<br> <TabAtkins> TabAtkins: We could probably use a note in Fonts 4 that the animation behavior has changed.<br> <TabAtkins> myles: Yes.<br> <TabAtkins> astearns: Objections?<br> <TabAtkins> RESOLVED: Font selection algorithm has different behavior during animation than Fonts 3; we will add a note to that affect in Fonts 4.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1579#issuecomment-319969692 using your GitHub account
Received on Thursday, 3 August 2017 13:32:18 UTC