- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 14 Feb 2012 14:01:17 -0500
- To: Aryeh Gregor <ayg@aryeh.name>
- CC: public-css-testsuite@w3.org
On 2/14/12 1:56 PM, Aryeh Gregor wrote: > On Tue, Feb 14, 2012 at 1:26 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote: >> Say you have a transition from "width: 100px" to "width: 200px" that's >> supposed to take 1s. When you do whatever you think will trigger the >> transition you start a 500ms timer. When that timer fires, you examine the >> width of the element. It should be 150px, to some tolerance. >> >> If desired, random error can be reduced somewhat by doing this whole >> operation multiple times. >> >> The question is what the tolerance should be. And that depends on what the >> random and systematic errors involved are, what their typical sizes are, and >> which of them are allowed per spec. > > If there are tight guarantees in practice on when the timer fires, Which timer? The setTimeout timer, or the animation one? > If there aren't tight guarantees in practice, and the timer will often > decide to fire whenever it feels like it in real browsers, then pages > can't depend on the behavior. The point of this exercise is to prevent having to write a labor-intensive manual reftest.... > In any event, we should be able to test this directly, not with a new API. Yes, that was my point. >> Obviously for colors that doesn't work, unless you use SVG to somehow >> composite things together and use feColorMatrix to map differences to >> something noticeable. > > Or you can have it flip back and forth between the two pages every few > tens of milliseconds. Then it will flicker if there are any > differences. This would work best with animations that repeat > indefinitely, of course. Yes, that would work. The big issue is the manual testing needed. > Sure. That's also an example of something that animated reftests could handle. Yes, agreed, modulo the usual caveat. -Boris
Received on Tuesday, 14 February 2012 19:01:57 UTC