- 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