Created attachment 460214 [details]
1. Load attached testcase.
2. Hover the orange area.
The orange area's width suddenly jumps to twice its original width.
The orange area's width should grow gradually (in response to the font-size transition).
The element here has a width specified in `em` units, and hovering triggers a change to `font-size` which triggers a CSS transition. That should add a value for `font-size` to the cascade, per https://www.w3.org/TR/css-transitions-1/#application , which should in turn influence the resolution of `em`-valued properties.
Safari 15.5 gives ACTUAL RESULTS.
Firefox and Chrome give EXPECTED RESULTS.
Note: I ran across this bug due to a bug report in Firefox, which turned out to be the reporter inadvertently depending on this WebKit bug. (Chrome matches Firefox's behavior FWIW.)
That report was https://bugzilla.mozilla.org/show_bug.cgi?id=1774014, which I closed as invalid since Firefox and Chrome are pretty-clearly following the spec.
WebKit happens to match the reporter's expectations over there, but I'm pretty sure that's just an accident and is essentially due to this bug here. If/when you fix this bug, I suspect you'll match Firefox and Chrome on the jsfiddle and attached testcase on https://bugzilla.mozilla.org/show_bug.cgi?id=1774014 .
Thanks for filing this Daniel. Do you know whether this is already covered by WPT?
I think this might be covered by the css/css-transitions/transition-base-response-*.html tests that WebKit is the sole engine to fail :(
Created attachment 460235 [details]
CSS Animation of font-size combined with relative width value
Adding another test where we use a CSS Animation to animate font-size. In that example, the em-based width is never updated.
(In reply to Antoine Quint from comment #3)
> Thanks for filing this Daniel.
Thanks for taking a look!
> Do you know whether this is already covered
> by WPT?
I don't know offhand, no (though it sounds like you might've subsequently found some related WPT tests).