Bug 78480 – CSS transition of text-shadow not smooth from CSS animation

• Status: NEW
• Component: CSS

Created attachment 126743 [details]
testcase #1

STR:
1. Hover pointer on text and watch the text-shadow values transition for 2 seconds.
2. Keep hovering for another 2 seconds when the animation should begin.
3. See text-shadow disappear.
4. Unhover pointer and see text-shadow transition back from the values it was before it disappeared

Expected results: text-shadow should animate
Actual results: text-shadow vanishes

Created attachment 126864 [details]
testcase #1 corrected

First version of the testcase omitted a colour value in the animation of text-colour. This version includes it. So #3 in the steps to reproduce no longer happens, but #4 is still apparent in that the shadow doesn't transition from wherever it is in the animation when unhovering, so I'm morphing this bug to deal with that issue.

(In reply to comment #1)
> First version of the testcase omitted a colour value in the animation of text-shadow.

Fixing my first sentence in that comment, it erroneously said text-colour.

[Simon Fraser (smfr)]

Does this happen with a simple property like 'left', or just text-shadow? The testcase is rather complex.

[Shane Stephens]

Created attachment 127300 [details]
Test case using left: property

[Shane Stephens]

Confirmed that this behavior occurs when animating left: property as well.

[Simon Fraser (smfr)]

I think this is correct behavior. When you unhover, the animation is immediately removed. The element snaps to its unanimated (but hovered) position, then transitions back from the hovered to the unhoverted state.

[Shane Stephens]

The correct behavior isn't specified and probably should be, but I don't think it's clear that the animation should be removed before the computed style for the from state of the transition is measured.

[Simon Fraser (smfr)]

There was some recent discussion on the interaction of transitions and animations. However, since animations override almost everything else, I think the current behavior is reasonable.

[Shane Stephens]

The problem with the current behavior is that it implies the following steps, specific to the case where there's an animation change as part of a computed style change.

(1) computed style changes
(2) animation portion of computed style is removed
(3) computed style is measured (transition from style)
(4) remaining parts of computed style change are applied
(5) computed style is measured again (transition to style)

Why is the change application split across two different steps? Why is there a special additional measurement of computed style just because of the presence of the animation?

[Simon Fraser (smfr)]

The spec should really define a behavior here. See the unresolved thread starting at <http://lists.w3.org/Archives/Public/www-style/2012Jan/1274.html>.

[Shane Stephens]

Agreed that we need to wait for the correct behavior to be specified before taking further action on this bug.