It looks like this only happens in cases where the "start" `em` length (resolved in the "start" font-size) would resolve to precisely the same pixel-value as the "end" `em` length (resolved in the "end" font-size). I suspect this triggers a special case where we decline to play the transition for that property (for `padding` in this case) and we just immediately jump to the new specified value; and then after that jump, it looks like the property starts animating but really it's just holding a fixed specified value in terms of `em` units, and the value of an `em` is just changing out from under it. The Firefox/Chrome behavior here might be required by the spec? I seem to recall that transitions are explicitly triggered (for a property) whenever the computed value of that property changes. And in this case, the computed value is not changing, which is presumably what makes us skip the transition...
Bug 1774014 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
It looks like this only happens in cases where the "start" `em` length (resolved in the "start" font-size) would resolve to precisely the same pixel-value as the "end" `em` length (resolved in the "end" font-size). I suspect this triggers a special case where we decline to play the transition for that property (for `padding` in this case) and we just immediately jump to the new specified value; and then after that jump, it looks like the property starts animating but really it's just holding a fixed specified value in terms of `em` units, and the value of an `em` is just changing out from under it. The Firefox/Chrome behavior here might be required by the spec? I seem to recall that transitions are explicitly triggered (for a given property) whenever the computed value of that property changes. And in this case, the computed value is not changing, which is presumably what makes us skip the transition...