Implement https://drafts.csswg.org/css-transitions-1/#starting from CSS Transitions.
<rdar://problem/41000798>
Created attachment 342939 [details] Patch
Comment on attachment 342939 [details] Patch Attachment 342939 [details] did not pass win-ews (win): Output: http://webkit-queues.webkit.org/results/8232952 New failing tests: transitions/transition-to-from-auto.html animations/transition-and-animation-3.html imported/mozilla/css-transitions/test_animation-ready.html
Created attachment 342949 [details] Archive of layout-test-results from ews200 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews200 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment on attachment 342939 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=342939&action=review > Source/WebCore/animation/AnimationTimeline.cpp:171 > +void AnimationTimeline::updateCSSAnimationsForElement(Element& element, const RenderStyle* currentStyle, const RenderStyle& afterChangeStyle) Can you keep the currentStyle as a &, since you check for null when you call the method? I guess you still have the case where afterStyleChange has a value but currentStyle doesn't?
(In reply to Dean Jackson from comment #5) > Comment on attachment 342939 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=342939&action=review > > > Source/WebCore/animation/AnimationTimeline.cpp:171 > > +void AnimationTimeline::updateCSSAnimationsForElement(Element& element, const RenderStyle* currentStyle, const RenderStyle& afterChangeStyle) > > Can you keep the currentStyle as a &, since you check for null when you call > the method? I guess you still have the case where afterStyleChange has a > value but currentStyle doesn't? Yes, see the call site in TreeResolver::createAnimatedElementUpdate(). CSS Transitions are guaranteed to have before and after styles, but CSS Animations aren't.
Committed r232946: <https://trac.webkit.org/changeset/232946>