- From: Simon Fraser <smfr@me.com>
- Date: Mon, 13 Feb 2012 16:27:19 -0800
- To: Aryeh Gregor <ayg@aryeh.name>
- Cc: public-css-testsuite@w3.org, Edward O'Connor <eoconnor@apple.com>, "L. David Baron" <dbaron@dbaron.org>
On Feb 13, 2012, at 11:33 am, Aryeh Gregor wrote: > (Sorry if I CC'd anyone who's already on this list -- I don't know > who's subscribed.) > > There are currently no tests at the W3C for transitions or animations, > and we need tests to be able to get to PR. (Plus just to test > interop.) It's not obvious what sort of tests we want here -- regular > JavaScript-based tests and reftests can't really test the > requirements, because setTimeout() isn't precise enough. Both Gecko > and WebKit (maybe other engines too?) have internal testing frameworks > for transitions and animations: > > http://trac.webkit.org/browser/trunk/LayoutTests/animations > http://trac.webkit.org/browser/trunk/LayoutTests/transitions > http://hg.mozilla.org/mozilla-central/file/tip/layout/style/test/test_animations.html > http://hg.mozilla.org/mozilla-central/file/tip/layout/style/test/test_transitions.html > > WebKit seems to use > layoutTestController.pauseAnimationAtTimeOnElementWithId; Gecko seems > to use SpecialPowers.DOMWindowUtils.advanceTimeAndRefresh. As a > starting point for possibly working out a format for standard > transition/animation tests, could Gecko and WebKit people perhaps give > an outline of how their internal tests work, so we could figure out if > the approach of one or the other would be suitable for standardizing? > Ideally, we'd want to be able to test both computed style and > rendering at arbitrary and reasonably precise times. WebKit has the following on window.layoutTestController (only available in the test environment): bool pauseAnimationAtTimeOnElementWithId(string animationName, double time, string elementId); bool pauseTransitionAtTimeOnElementWithId(string propertyName, double time, string elementId); Both only affect the specific transition/animation specified; WebKit has no notion of a "document timeline". These methods return false if they fail for some reason: the element wasn't found, or the transition/animation is not running on the element. The transition/animation will jump to the specified time (jumping backwards if necessary), which will affect computed style, and the visible rendering. Once paused, the transition/animation cannot be restarted. I do see a strong need for an API like this for the test suite, but I'd be worried about exposing something to content. I would never want a page on the open web using a method like this. Simon
Received on Tuesday, 14 February 2012 00:28:09 UTC