[css-fonts-4] Animation type font-weight, discrete?

[drott]

https://drafts.csswg.org/css-fonts-4/#font-weight-prop describes the animation type as "discrete". What does this mean and what is the intended behavior?

Does it refer to a behavior as defined in https://drafts.csswg.org/css-transitions/#animtype-font-weight, or is the intention to animate as https://drafts.csswg.org/css-transitions/#animtype-integer? Or should this rather be animated as , same as stretch?

In my opinion, at least implementing this as discrete jumps from 100, 200, ..., 900 seems odd for variable fonts, which would make it necessary to use font-variation-settings to achieve a smooth weight animation.

[SebastianZ]

Looks like it should refer to the font weight animation type, because the definition in CSS Fonts 3 also refers to it.

Having said that, the discussion whether the discrete transition between the number values should be changed to a smooth one is then rather related to CSS Transitions.

As font-weight was changed in CSS Fonts 4 to allow arbitrary <number> values (should that actually be <integer>?) instead of discrete values, it makes sense to redefine the transition so that it also allows <number> (resp. <integer>) values.

Therefore, the font weight animation type in CSS Transitions 1 may either be changed accordingly or removed in favor of specifying an animation type of <number> (or <integer>) in CSS Fonts 4.

Sebastian

[svgeesus]

Agreeing it makes no sense for this to be discrete in fonts 4.
Therefore, it makes little sense for fonts 3 to specify something different here.
Maybe say that animation is discrete if variable fonts are not supported?

[LeaVerou]

Even in Fonts 3, the effect would be the same even if animated like a <number> due to font-weight resolution rules, no?

[litherum]

No, due to the font selection algorithm, the value can still be interpolated numerically, and the result will appear discrete. (At certain thresholds, a new font will be chosen, so it'll look discrete.)

It should just be animated as <number>, just like font-stretch.

[LeaVerou]

No, due to the font selection algorithm, the value can still be interpolated numerically, and the result will appear discrete. (At certain thresholds, a new font will be chosen, so it'll look discrete.)

I’m confused. You said no, then proceeded to agree with me.

[litherum]

Sorry for the confusion. I totally agree with you, Lea. (My "no" was directed at an earlier post.)

[litherum]

I just forgot to list the "Animatable" keyword in the propdef table

[fantasai]

Reopening to see if fonts-3 and transitions-1 should be updated accordingly. If so, fonts-3 probably needs some prose to explain how to round to the nearest 100 when looking up the weight (rather than at computed value time).

[litherum]

https://drafts.csswg.org/css-transitions/#animtype-font-weight

font weight: interpolated via discrete steps (multiples of 100). The interpolation happens in real number space and is converted to an integer by rounding to the nearest multiple of 100, with values halfway between multiples of 100 rounded towards positive infinity.

Is this insufficient?

[litherum]

Adding to F2F agenda, so removing Agenda+

[litherum]

There is a small behavior change here. 🙁

Consider animating font-weight between 400 and 600, and at the current time, the "real number" is 425.

In the old model, 425 gets rounded to 400, which causes the old font matching algorithm to search the following list:
400, 500, 300, 200, ...

In the new model, 425 doesn't get rounded, and the new font matching algorithm searches the following list:
425, ..., 400, ..., 300, ..., 200, ..., 500

Therefore, if the system has installed fonts at weights of 500 and 300, in the first model, the 500-weight font will be selected, and in the second model, the 300-weight font will be selected.

Indeed, in the old model, the 500-weight font will be selected throughout the entire animation. This means that the new model will show a font which would never be shown before.

[litherum]

We could solve this by making the font selection algorithm more complicated, or we could just swallow the behavior change.

Animation of font weights in the old world was fairly uncommon, so I'm not sure that this behavior change is very important. Keeping the new world's font selection algorithm as simple as possible seems important because it already had to get way more complicated because of variation fonts.

WebKit has had the new matching algorithm in our betas, Safari Technology Preview builds, and nightly builds for weeks/months, and I haven't seen a single bug about this.

[drott]

+1 for not making the algorithm more complicated, rather accepting this behavior change.

[astearns]

[css-meeting-bot]

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.

The full IRC log of that discussion

<fremy> Topic: Animating font weight
<astearns> github: https://github.com//issues/1579
<fremy> myles_: two things here
<fremy> myles_: 1. requested font weight
<fremy> myles_: 2. available options in the font
<fremy> myles_: then algorithm match one to the others
<fremy> myles_: for historical reasons, if you want 400 and it is not possible
<fremy> myles_: search will be 300, then 500, then 200, then ...
<fremy> myles_: variables fonts can have much more arbitrary values
<fantasai> 500, then 300, then 200 I think
<fremy> myles_: so I tried to come up with a solution for this
<fantasai> s/this/generalizing this/
<fremy> myles_: (connecting laptop to tv screens)
<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
<fremy> fantasai: why not directly 400 -> 500 instead of 400 then discretely 500
<fremy> fantasai: doesn't seem very logical
<fremy> TabAtkins: the old model did that
<fremy> fantasai: but you could not express 430, it needed to be hundred multiples
<fremy> fantasai: the goal of the algorithm was that 400 and 500 were very common values
<fremy> fantasai: but 300 is often lightweight
<fremy> fantasai: this proposal preserves the compat, but not the spirit
<fremy> fantasai: I would prefer to connect the 400 -> 500 range
<fremy> TabAtkins: yes, it is less weird
<fremy> myles: if there is concensus, i am ok with this
<fremy> fantasai: this would evolve the old algorithm, not run some algorithm after it
<fremy> fantasai: proposal means if we did 400 then 500 then 300, now we do 400 -> 500, then 500 -> 300, ...
<fremy> fantasai: obviously some values will not match
<fantasai> basically play "connect the dots" with the old search points
<fremy> fantasai: because they have been searched already
<fantasai> which might go over some ranges multiple times, but of course the UA would optimize those out
<fremy> (whiteboard discussion)
<fremy> (the discussion seems to be about what fantasai's idea does if you search for 450 not 400)
<fremy> (and related cases like 250 or 550)
<Rossen> [fantasai and myles are having hell of a time connecting dots and lines on the white board]
<TabAtkins> Split the weights into three categories:
<TabAtkins> light - < 400
<TabAtkins> medium - 400 <= x <= 500
<TabAtkins> bold - > 500
<TabAtkins> For light, first search from x => 0, then x => 1000
<TabAtkins> For bold, first search from x => 1000, then x => 0
<TabAtkins> For medium, several possiblities.
<TabAtkins> Never mind, bolder is better, so medium's category is: search x=>500, then x => 0, then x => 1000
<fremy> RESOLVED: font-weight matching described before
<TabAtkins> ScribeNick: TabAtkins
<TabAtkins> myles: Previously you could animate font-weights, even tho they weren't numbers.
<TabAtkins> myles: You animated a number, then rounded to nearest 100, *then* invoked the font selection algo.
<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.
<TabAtkins> myles: For variable fonts, you don't have to round. This is a good thing.
<TabAtkins> myles: But rounding might change which case you fall into.
<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.
<TabAtkins> myles: So two options: undo what we just did and make it more complicated...
<TabAtkins> myles: Or say that animating font-weights before variable fonts wasn't often used, and just accept the behavior change.
<TabAtkins> fantasai: I think there's not much objection to computing font-weight and its animation to be a general integer.
<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?
<TabAtkins> dbaron: There are fonts with more than just 100, 200, etc weights; seems like it would be better to make that work.
<TabAtkins> dauwhe: I have a font with weights spaced every 5.
<TabAtkins> dbaron: So I think we should just make the change; we'll see if there's any problem.
<TabAtkins> myles: I think we alreayd have an old resolution to let weight accept any integer, actually.
<TabAtkins> dbaron: Does the spec really mean <number> rather than <integer>?
<TabAtkins> myles: <number> is right; variables axises can accept any float in the range.
<TabAtkins> fantasai: So Fonts 3 needs to be updated; do we want to allow it at parse time too?
<TabAtkins> dbaron: I dont' think Fonts 3 needs updating; this is a new feature, the property just supports more values than it used to.
<TabAtkins> fantasai: That's fair.
<TabAtkins> TabAtkins: We could probably use a note in Fonts 4 that the animation behavior has changed.
<TabAtkins> myles: Yes.
<TabAtkins> astearns: Objections?
<TabAtkins> RESOLVED: Font selection algorithm has different behavior during animation than Fonts 3; we will add a note to that affect in Fonts 4.

[tabatkins]

Specifically (to summarize the picture):

1. If font-weight < 400, search down to zero, then search up to 1000.
2. If font-weight > 500, search up to 1000, then search down to 0.
3. If font-weight is between 400 and 500, first search up to 500, then search down to 0, then search up to 1000.

Then, we remove the "round to nearest 100" behavior from animations. This is a probably-minor change to font-weight animations, which we think are fairly rare in legacy, pre-variation-axis pages anyway, and the change itself isn't very significant; you just swap between the intermediate font faces at slightly different times, but end up with the same result on either end.

[ewilligers]

Should the syntax support <number>, and clamping to the range 0..1000, so animated values can round-trip?

[drott]

I think in the IRC log Myles confirms, it should animate as <number>. I'm in favor of a clamping range, but I think to be consistent with https://drafts.csswg.org/css-fonts-4/#font-weight-numeric-values it should be 1..1000:

Only values greater than or equal to 1, and less than or equal to 1000, are valid, and all other values are treated as parse errors.

[FremyCompany]

Just a ping that css-fonts-4 still mentions font-weight as being an <integer> while we now implement it as a <number>

[litherum]

@drott is right, and I don't believe there's anything to do here regarding that point.

@FremyCompany I'll do this now.

[litherum]

Whoops, this was already done. 0d2eca79ba